> You're not kicked out if you "dare" (how brave!) ask a question about it. You're welcome to chat about it on #nonguix. Is it really that hard to accept that #guix is not #nonguix and that we don't discuss proprietary software on the main channels? So... if I go to the official channel to discuss guix and I said the forbidden word "CUDA" I get kicked off? You wrote a sentence in a tone that implies it disagrees with…
"CUDA" is not a forbidden word. Where does that idea come from? Here: CUDA, CUDA, CUDA! If you go to the official channels and ask about CUDA people like me will likely tell you that CUDA is proprietary software, so we don't cater to it in Guix. If you then acted all offended and angry that would be the end of my interactions with you; otherwise I'd tell you the right venue to ask for help with CUDA without starting…
You acknowledge that I'm not allowed to talk about CUDA in the guix community but then are turning it into some sort of game?
This is the childish and dismissive attitude of the guix community.
The semantics are simple and necessary, yes. The syntax is kind of crap in some ways (in others it's awesome and I wish other languages were as lightweight). Syntax in general is a bikeshed, but that doesn't mean we can't objectively critique things like having function definition being a mere ":". That one on its own is probably responsible for much of the indecipherability. Also some of the higher level constructs…
> overrideDerivation/overrideAttrs/override, I still don't fully get Packages are implemented as functions that take dependencies as arguments, do some stuff and ultimately output the result of calling mkDerivation (i.e. a derivation). `override` allows you to change the arguments of the package, while `overrideAttrs` allows you to change the arguments of mkDerivation: the implementation of the package itself. `overr…
Ah, I had forgotten `override` is easy. Rereading that page I still don't get the difference between `overrideAttrs` and `overrideDerivation`. `overrideAttrs` is newer and preferred, yet it doesn't spell out where you cannot use it and have to fall back to `overrideDeriviation`. And looking through my Nix code I've got various uses of `overrideDerivation`, which most likely means I tried `overrideAttrs` only to have it not work, so I tried the "deprecated" version and it did.
I've tried to use Nix on and off for years. I always run into issues where I need to write some package and (1) I get mired in packaging low level transitive dependencies and things which seem like they should be easy end up being nearly impossible (2) Basic things like figuring out the argument types for a particular nixpkgs function take an insanely long time. It always involves grepping around the whole repo (nixp…
Have you looked into Guix? In some ways it's a bit simpler and cleaner because it is a much more recent effort and Scheme is somewhat easier. It might help with the learning process in case you disliked Nix. GuixSD does have some other drawbacks. I'm personally running NixOS but both are very cool. Nix certainly has a steep curve, but simple things are not that hard. I got committed to migrate to Nix one Monday. I sp…
I've tried a bootable vm image but couldn't figure out how to configure, the docs only cover the installer, no examples, so I gave up. It seems like it's a Guile recipe for an OS. I want the OS with docs, examples, maybe a simple instalker to get everything bootstrapped. Then I could learn to write recipes. Other than that, Guile is attractive and so is GNU Shepherd, which is why I tried it in the first place.
I used Nix and NixOS for more than a year as my daily driver. I've contributed to Nixpkgs. I agree with the author on most if not all of their points. Here's some advice: If you're interested in Nix, take steps not leaps. Use the Nix package manager. It's a great addition to distros like Debian. Then maybe use Home Manager (even though I think Home Manager is way over-hyped, see below). Then write a bunch of derivati…
> And about Home Manager, the reason why I think it's over-hyped is because it provides a declarative approach to something that was... already declarative. Your $XDG_CONFIG directory does not need a leaky Nix abstraction on top of it I don't really agree, I spent about 30mins to get my home-manager config to support an m1 mac [0]. I don't really want to think how long it would take me to look up all of the homebrew…
WRT Home Manager, that makes sense and portability is definitely a cool benefit of Home Manager. But keeping all of your config for multiple workstations in one has drawbacks too. I found myself frustrated when I wanted to install something but I forgot to push changes from another computer so I needed to stash or rebase later on. Just to install a package! I only have one workstation and a small amount of servers, and I tried running NixOS on everything. It worked well (I still have multiple servers running NixOS actually) but for me, the benefits just weren't worth the overhead of living full time in Nix land. Now I use Debian stable for new servers and I prefer it. But yeah, lots of personal preference here. And WRT nix-env, it seems troubling to me that the fundamental tool of the Nix CLI is something that you recommend people stay away from. I think you may have be right about that recommendation, but I think it shows that Nix as a product is far off from being a "pick up and run" tool for average developers. I really hope that it will somehow get to that point but, like the author says, I don't think it will be Nix itself because it has burrowed itself into a bespoke, complicated UX that has a huge learning curve. I like simple things with elegant UX so that's where I'm coming from. There's just so many ways to use Nix, like, TOO many ways. But I'm glad that they're pioneering this space.
I didn't go all-in with nixos -- and I'm thankful I didn't. I simply tried using it for local development. I thought that I could replace the various language version managers with nix. I spent weeks working with nix to understand the language, how to use it, and reading as much documentation/blogs as possible. One really frustrating thing about nix I noticed early on is the lack of support for older language version…
I am all-in on nixos. I've also experienced those problems, but I for one am glad that those don't work. Let me explain. My use-case for Nix is to make my build system so reproducible that, if I get back to the project in five years, it should still compile, and if I give it to someone else, they should be able to make it work without any issue. Like the install steps for them should be as simple as "Install nix, the…
This is a maximalist position and an admirable goal. As far as I can tell though, this forces Nix (or the developer) to get into the business of re-packaging entire ecosystems.
Looks like these things are being addressed, although from past of experience it probably will take several years :( (when I started using Nix, 3 years there was a talk about this new thing called flakes, now the version 2.4 already contains it, but it is still locked behind experimental features) 1. https://github.com/tweag/nickel - it is a typed language, that might in the future replace nix language 2. looks like…
There is also https://github.com/purenix-org/purenix
That's interesting, looks like it is transpiler that could be used immediately if someone doesn't mind the extra step. Thank you for sharing it.
BTW: the Nickel has chance to end up replace Nix language as I saw author of Nix (Eelco) is also contributing to it. I don't think it can transpile to a nix code.
> overrideDerivation/overrideAttrs/override, I still don't fully get Packages are implemented as functions that take dependencies as arguments, do some stuff and ultimately output the result of calling mkDerivation (i.e. a derivation). `override` allows you to change the arguments of the package, while `overrideAttrs` allows you to change the arguments of mkDerivation: the implementation of the package itself. `overr…
Ah, I had forgotten `override` is easy. Rereading that page I still don't get the difference between `overrideAttrs` and `overrideDerivation`. `overrideAttrs` is newer and preferred, yet it doesn't spell out where you cannot use it and have to fall back to `overrideDeriviation`. And looking through my Nix code I've got various uses of `overrideDerivation`, which most likely means I tried `overrideAttrs` only to have…
I think the manual is intetionally flying over `overrideDerivation` because it shouldn't be used. To understand the difference you'd have to know that `stdenv.mkDerivation` is a library function that wraps the Nix primitive `builtins.derivation`, which is what actually makes a derivation.
`overrideAttrs` changes the arguments of the former, while `overrideDerivation` changes the arguments of the latter. The reason is it's "deprecated" is that it forces a full evaluation of `stdenv.mkDerivation` before it can continue and it override the lower-level derivation, so some niceties that Nixpkgs provides don't work with it.
Many of the necessary fixes do end up getting pushed upstream, though, thinking especially of stuff like converting CMake projects to use the GNUInstallDirs standard, so there is a benefit to the strictness work that extends beyond even just the Nix community itself. Of course, sometimes those kinds of changes just never get merged, for a variety of well-understood open-sourcey reasons, eg: https://github.com/pocopro…
And now that PR is merged...
Well yes. I wasn't intentionally shaming the poco project with the link, but having a bunch of attention drawn all at once does have a way of moving these things along.
The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages. I don't agree with this direction, though. Basic packages can already be described pretty simply using native nixlang, and the complexity scales well— you can add patches, fixups, flags on dependencies, extra fetcher args, whatever and it's a pre…
> The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages. No, I'm talking about things like classes, abstract data types, modules, type checking and docstrings. "Programming in the large". Nixpkgs and NixOS does its own hand-rolled versions of these for each subproject. Eventually (a long time from no…
Okay, yes, I agree with all of that. Flakes are kind of a module system, but having clearer semantics around functions and classes would definitely help with both code readability and producing better stack traces.
And a proper type system would be awesome.
Regarding docs, it is interesting that portions of the nixpkgs source do seem to have docblock-like comments above the functions, but AFAICT there's no formalized process for extracting or rendering those. Given that https://github.com/nix-community/rnix-parser exists, I wonder how big of a leap it would be to actually extract those, render them into rST pages, and generate a searchable Sphinx manual.
Yeah, one of the consequences of purity is that packages can't/shouldn't refer to paths outside of the nix store (/nix/store), so it needs to be hardcoded. Otherwise you end up not being able to match hashes against a binary cache. The glibc issue you ran into is actually a prime example of this problem, and the version shipped in nixpkgs is patched to allow multiple instances by changing various hardcoded paths to t…
I've never understood why Nix cannot simply rewrite those paths to "look like" the canonical ones when calculating hashes. Surely a pre-processing rule could transform "/home/me/nix" to "/nix", based on my Nix configuration.
Again, purity. Changing the inputs (the derivation with all its referenced paths) would result in the same hash output, and someone substituting your package from a binary cache would receive a package that doesn't work on their system, yet matches the expected hash.