Comment by chriswarbo | Hacker News Reader

Comment by chriswarbo | Hacker News Reader

As a NixOS user I've certainly encountered some of these issues. While Nix and NixOS are really nice, the first thing I'd recommend to a new user would be to learn the Nix language, as it's pretty much a requirement for getting anything done.

I agree with the author that per-user configuration is a bit overkill for the common use-case of a single user machine, but you have to go out of your way to use it (via the "nix-env" command), so I think it's a bit of a non-issue. Since Nix can be used from any user's home directory anyway (this is often how it's used on non-NixOS systems), it's not necessary for Nix/NixOS to contain this per-user feature; however, by doing so they gain a huge space optimisation by re-using the same store. The same can be said for NixOS containers, which I don't use but I see why it's there.

As for making packages available at runtime, that's what the "propagatedBuildInputs" attribute is for. Sometimes Nix can actually automagically figure out runtime dependencies, since it looks through files as they're installed to see if they contain references to other store paths; if so, those paths are added to the runtime dependencies.

Love NixOS. I spend about a month in it. While it did feel very complete, I did end up reverting to Arch just for lack of time. I agree that you have to learn the nix packaging language in order to make good use of the system. When I have more time, I will get back to it.

Another issue I had was around config methodology - specifically for the desktop use case. For example, in Gnome I wanted to tune my brightness and mouse sensitivity. In most desktop cases you want to adjust those things every session and have that remembered between reboots. But that violates the Nix config system. Perhaps there is a middle ground where those session specific configs can be stored instead of putting them in the global config.

Also the Nix package manager is great - mostly that it is platform agnostic, but the real power is in NixOS's global config file - which is essential for SERVER stability.

I will say that it was an enlightening experience as a whole and some of these concepts are being taken very seriously in other projects. I cant wait for non-deterministic build systems like Puppet and Salt to be a thing of the past. Nix, Guix, Snap packages (and the like), and Docker are much safer and dependable.

No, that is not what `propagatedBuildInputs` is for. `propagatedBuildInputs` should be used very sparingly, in most cases wrappers are the better solution.

For example, consider if every package that contained bash scripts would put bash in `propagatedBuildInputs`. Then I could not use a different version of bash for my user environment than those packages I installed used!

Also, `propagatedBuildInputs` are not even propagated into the user environment, the attribute that does that is `propagatedUserEnvPkgs` (not sure if that name is fully correct), and it is very sparingly used within nixpkgs.

> `propagatedBuildInputs` should be used very sparingly, in most cases wrappers are the better solution.

propagatedBuildInputs is a widely-applicable hammer, and the article's tone made it sound like the author wanted a quick fix. Wrappers certainly provide a better outcome, but require more thought and case-by-case caveats; i.e. they're more appropriate for widespread adoption in nixpkgs, but not so much when throwing something into packageOverrides to stop a build script complaining.

> For example, consider if every package that contained bash scripts would put bash in `propagatedBuildInputs`. Then I could not use a different version of bash for my user environment than those packages I installed used!

Well, wrappers aren't the answer here either; fixing up the shebangs is. Functions like stdenv.mkDerivation will do that automatically.

I've not come across propagatedUserEnvPkgs before, but I also don't make much use of the user environment. I spend most of my time in nix-shells :)

Perhaps that was a feature added after the article was written. It dates from January.

The Nix language itself is very small and simple; much of the functionality comes from the libraries which come bundled in the "nixpkgs" repository. The normal way to define a package is via the stdenv.mkDerivation function, which has accepted propagatedBuildInputs for at least the last few years (as long as I've been using Nix and NixOS).

To make things even easier, there are functions targeted at specific languages, like buildPythonPackage. That's taken propagatedBuildInputs for as long as I can remember, and since Python is interpreted that's basically the default way to use it (there are very few Python packages which are only required during build/installation time).

If the worst comes to the worst, you can always just define a "buildCommand" attribute containing arbitrary bash code. It'll be executed in a temporary directory, and inherit a bunch of environment variables (the most important being $out, which is the path which Nix will install).

The "wrapProgram" function used in builders takes a --path (IIRC) parameter that helps with this, useful in conjunction with the "makeBinPath" function which takes a list of packages and concatenates their path entries.

Reply on news.ycombinator.com