I think with the introduction of Nickel [1], Nix packages would be rewritten in it over time, which may be a good thing (types) or a bad thing (another fragmentation after flakes) depending on your point of view.
On the other hand, Guile is not a DSL but a general purpose language or a Lisp (Scheme to be exact), so it's not actually a downside compared to a DSL in my view.
I myself am torn between these two. Nix community is larger and they have more packages. Guix, being a GNU project, obsessing over ""non-free"" sure won't help in its adoption. Even debian folks toned down their stance on this, why couldn't Guix do so too?
I find Nix to be very close to the perfect DSL for what it does, and I like it quite a lot. But then I never bothered to look at Guix closely -- is its DSL at least lazy? Are there any honest comparisons wrt verbosity and awkwardness of Nix and Guix for stuff both are supposed to be good at?
No idea what "making NixOS compatible with other programming languages" is supposed to mean. On the face of it the phrase is, well, baffling. Would you care to elaborate?
Well. One is a language that has metasyntactic abilities and a decent standard library. One is not. Defining a package in guix is a lot nicer than in nix
Opposite for me. Nix syntax is much more pleasant to use and while Nix error messages are by no means perfect, still more fun than digging through multiple layers of Scheme.
Does Guix have anything similar to Nix flakes yet?
I personally prefer Nix greatly it's just JSON with functions basically. I just find Guile expressions totally unreadable with the brackets everywhere.
How do Guix and Nix userbases and contributor resources compare?
I like Guix as a standalone package manager much much more. It has first-class support for single-file environment config, and it's in lisp! But a package manager system ultimately comes down to resources poured into maintaining and supporting packages, it's a bootstrap problem. It's clear that NixOS has substantial support. What about Guix?
I like Guix better in principle as well, but it should be clear that its principled stance on what software can be packaged means it's a nonstarter for many people.
I very much prefer the Guix community because based on my personal experience, it is more friendly and helpful than the Nix community. The main help ressources are the help-guix mailing-list and the IRC channel.
How would one use a modern IDE in this environment especially when you have multiple projects with different dependencies open at the same time? Would one need to install the IDE as a dependency of a project? Would all the IDEs have different settings?
I use Emacs installed for my user account (so not as a dependency of any project), and install an integration that works with 'guix shell' for per-project software configurations. Emacs' project.el extension allows me to switch between many projects easily.
That depends on what you want to containerize (which I assume you are after? If you don't containerize it works just like any other distro--it will be transparent to the IDE (because the IDE doesn't care that suddendly your gcc in PATH is in $HOME/.guix-profile/bin, or that pkg-config picks up packages in PKG_CONFIG_PATH which happen to be in /gnu/store/3248235325322332w-wrwqewewtew-libpng/lib/pkgconfig)).
Personally, I containerize the weird build tools I can't fully trust (vendor toolchains etc) and have wrapper scripts (written in bash) in PATH. The IDE is none the wiser that those are containerized.
It's possible to have multiple packages in a permanent custom profile, if that's what you mean (that's kinda the manifest stuff at the end of the article). Those can be started all in the same container. For example, yes, you can have a profile which contains java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain for your specific project. This does not change your specific project's package.
If you are asking whether java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain would be referred to in your guix.scm, I wouldn't do that. But in your profile? yes.
>Would one need to install the IDE as a dependency of a project?
Why that? The IDE, like a text editor, is a developer tool and doesn't end up with the project artifacts that you are building. So it's not any kind of dependency of the project.
For example when you build Java projects using Eclipse, your projects are actually built using gradle and then openjdk. So gradle is a native-input, openjdk is a build system input and Eclipse is NO dependency of your project's guix package.
Your developer profile, however, can contain multiple packages (in the container). That's not what's built when you build just the package using "guix build -f guix.scm", though (those builds are isolated).
Think of a profile as something like as set of packages and also environment variables that you can refer to as a whole (containerize etc) using a new fixed name.
Or think of companies where you have different hats on. Depending on the hat, you would have a profile--so the developer hat doesn't actually have the tools to delete production :)
Most other distributions have just one global profile, not even per user. In guix, you have a default profile ".guix-profile" per user, and you can make any number of extra ones (no sudo needed).
>when you have multiple projects with different dependencies open at the same time?
Hmm, I think I can see what you are getting at. I don't know whether there are IDE plugins that are guix-aware. Would be easy to do though (it would just use a custom build step as the only build step - "guix build -f guix.scm" . This automatically makes a container with your package, its build system and your package's dependencies in it and builds that (if dependency is not built yet, makes a container with that package and its dependencies in it and builds that, and so on, recursively). The IDE would then pick up the output of "guix build" which is the path to the result (somewhere in /gnu/store/...)).
The path names used inside and outside the container are the same, and the dependencies are kept around for a while, so the IDE will have a good time referring to those for headers etc when debugging or doing autocomplete.
So you can for example use WSL2 on Windows with a small Linux distribution and then extract the guix binaries from the website guix.gnu.org onto there, start guix-daemon in there and use guix like that. That said, I care about bootstrappable builds, so I can't recommend using a hypervisor I can't trust (Windows Hyper-V) as a base.
That's if you want the development environment.
On the other hand, for using guix packs of your software, you don't even need to install guix. Just unpack the pack as-is (or use docker).
Note: guix supports cross compilation, so you CAN just use --target=x86_64-w64-mingw32 and it will compile your program for Windows native just fine. The computer that is doing the building needs to be Linux- or Hurd-based, though.
Sometimes people come and try to port guix to cygwin or whatever but I have no experience in how far that is.
This is the only reason I haven't tried to use Guix. I love the concept, I want to use it, but it does not run on FreeBSD. And I would not invest time in a packaging system that works on my workstation but not on my servers.
It is sad to see so many Linux only software, especially when there is no technical reason not to support *BSD.
I love NixOS, but I am looking to move my workstation to Guix.
The reason is that, it seems NixOS do not sign their packages. I've checked the messaging platforms, and while there seems to be a consensus that its not needed, I'm at present unconvinced (especially since Guix, to my knowledge, do require signing).
On its own I'd actually be OK with looking past this, but the lack of documentation on mandatory access control, secure boot, and general sandbox consideration, makes me concerned on multiple fronts. Which is a shame, because like I said, NixOS is a delight to use.
The problem goes well beyond though: as far as I know, Guix is the only project that has a Git repository that users can authenticate when they pull from it.
What's the split like these days between users of Guix the package manager running on some other distribution vs Guix the distribution? Is one noticably more popular than the other?
There are many users of Guix at research institutes who aren't running Guix System (i.e. the full system). But the difference between Guix and Guix System is pretty small; even with just Guix you get the "guix system" command, so you can build containers and VMs that run Guix System. You only can't benefit from full-system rollbacks and the integration of Guix system services.
[+] [-] coldblues|2 years ago|reply
[+] [-] ducktective|2 years ago|reply
On the other hand, Guile is not a DSL but a general purpose language or a Lisp (Scheme to be exact), so it's not actually a downside compared to a DSL in my view.
I myself am torn between these two. Nix community is larger and they have more packages. Guix, being a GNU project, obsessing over ""non-free"" sure won't help in its adoption. Even debian folks toned down their stance on this, why couldn't Guix do so too?
[1]: https://github.com/tweag/nickel
[+] [-] cmm|2 years ago|reply
No idea what "making NixOS compatible with other programming languages" is supposed to mean. On the face of it the phrase is, well, baffling. Would you care to elaborate?
[+] [-] pmoriarty|2 years ago|reply
[+] [-] bjoli|2 years ago|reply
[+] [-] grumbel|2 years ago|reply
Does Guix have anything similar to Nix flakes yet?
[+] [-] rowanG077|2 years ago|reply
[+] [-] monday_|2 years ago|reply
I like Guix as a standalone package manager much much more. It has first-class support for single-file environment config, and it's in lisp! But a package manager system ultimately comes down to resources poured into maintaining and supporting packages, it's a bootstrap problem. It's clear that NixOS has substantial support. What about Guix?
[+] [-] Filligree|2 years ago|reply
I like Guix better in principle as well, but it should be clear that its principled stance on what software can be packaged means it's a nonstarter for many people.
[+] [-] mekeor|2 years ago|reply
[+] [-] bordercases|2 years ago|reply
[+] [-] ivanb|2 years ago|reply
[+] [-] mekeor|2 years ago|reply
[+] [-] davexunit|2 years ago|reply
[+] [-] dannymi|2 years ago|reply
Personally, I containerize the weird build tools I can't fully trust (vendor toolchains etc) and have wrapper scripts (written in bash) in PATH. The IDE is none the wiser that those are containerized.
It's possible to have multiple packages in a permanent custom profile, if that's what you mean (that's kinda the manifest stuff at the end of the article). Those can be started all in the same container. For example, yes, you can have a profile which contains java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain for your specific project. This does not change your specific project's package.
If you are asking whether java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain would be referred to in your guix.scm, I wouldn't do that. But in your profile? yes.
>Would one need to install the IDE as a dependency of a project?
Why that? The IDE, like a text editor, is a developer tool and doesn't end up with the project artifacts that you are building. So it's not any kind of dependency of the project.
For example when you build Java projects using Eclipse, your projects are actually built using gradle and then openjdk. So gradle is a native-input, openjdk is a build system input and Eclipse is NO dependency of your project's guix package.
Your developer profile, however, can contain multiple packages (in the container). That's not what's built when you build just the package using "guix build -f guix.scm", though (those builds are isolated).
Think of a profile as something like as set of packages and also environment variables that you can refer to as a whole (containerize etc) using a new fixed name.
Or think of companies where you have different hats on. Depending on the hat, you would have a profile--so the developer hat doesn't actually have the tools to delete production :)
Most other distributions have just one global profile, not even per user. In guix, you have a default profile ".guix-profile" per user, and you can make any number of extra ones (no sudo needed).
>when you have multiple projects with different dependencies open at the same time?
Hmm, I think I can see what you are getting at. I don't know whether there are IDE plugins that are guix-aware. Would be easy to do though (it would just use a custom build step as the only build step - "guix build -f guix.scm" . This automatically makes a container with your package, its build system and your package's dependencies in it and builds that (if dependency is not built yet, makes a container with that package and its dependencies in it and builds that, and so on, recursively). The IDE would then pick up the output of "guix build" which is the path to the result (somewhere in /gnu/store/...)).
The path names used inside and outside the container are the same, and the dependencies are kept around for a while, so the IDE will have a good time referring to those for headers etc when debugging or doing autocomplete.
[+] [-] ParetoOptimal|2 years ago|reply
This is automated with direnv and an extension for direnv in your ide so this transparently happens when you open that project.
tl;dr Ide plugin to use same PATH and stuff as nix develop
[+] [-] brabel|2 years ago|reply
[+] [-] dannymi|2 years ago|reply
So you can for example use WSL2 on Windows with a small Linux distribution and then extract the guix binaries from the website guix.gnu.org onto there, start guix-daemon in there and use guix like that. That said, I care about bootstrappable builds, so I can't recommend using a hypervisor I can't trust (Windows Hyper-V) as a base.
That's if you want the development environment.
On the other hand, for using guix packs of your software, you don't even need to install guix. Just unpack the pack as-is (or use docker).
Note: guix supports cross compilation, so you CAN just use --target=x86_64-w64-mingw32 and it will compile your program for Windows native just fine. The computer that is doing the building needs to be Linux- or Hurd-based, though.
Sometimes people come and try to port guix to cygwin or whatever but I have no experience in how far that is.
What's your use case?
[+] [-] mekeor|2 years ago|reply
[+] [-] cornedor|2 years ago|reply
[+] [-] galdor|2 years ago|reply
It is sad to see so many Linux only software, especially when there is no technical reason not to support *BSD.
[+] [-] plaguepilled|2 years ago|reply
The reason is that, it seems NixOS do not sign their packages. I've checked the messaging platforms, and while there seems to be a consensus that its not needed, I'm at present unconvinced (especially since Guix, to my knowledge, do require signing).
On its own I'd actually be OK with looking past this, but the lack of documentation on mandatory access control, secure boot, and general sandbox consideration, makes me concerned on multiple fronts. Which is a shame, because like I said, NixOS is a delight to use.
[+] [-] civodul|2 years ago|reply
However, only Guix has signed commits in its repository (the repo contains package definitions) and a mechanism for secure updates: https://guix.gnu.org/en/blog/2020/securing-updates/
The problem goes well beyond though: as far as I know, Guix is the only project that has a Git repository that users can authenticate when they pull from it.
[+] [-] superluserdo|2 years ago|reply
[+] [-] rekado|2 years ago|reply
[+] [-] foobarqux|2 years ago|reply