Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflections on NixOS

zenhack.net

Post reply on HN
Print view View original

11–20 of 102 posts

Re: Reflections on NixOS

#11

Post by chriswarbo »

haarts wrote: post #4
chriswarbo wrote: post #2

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 "ni…

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).

Re: Reflections on NixOS

#12

Post by bennofs »

zeendo wrote: post #8
Filligree wrote: post #6

Earlier quoted context omitted.

As a near-fanatic NixOS user (now!), I agree with both you and GP. The learning curve is brutal, so it took me a while to get started, but it's paid off several times over. It's unfortunate that humans can't trust each other enough that saying "You'll like it after a few months" is good enough, but it's also an inevitable fact of life; for starters, the speaker might be mistaken. I don't think NixOS is for everyone,…

Would you suggest the Nix Pills series now? I notice it's 2 years old.

I would suggest it, there is not much that has changed about the core of nix/nixpkgs, the nix language is quite stable and most changes have been additions rather than changing existing features.

Re: Reflections on NixOS

#13

Post by Filligree »

zeendo wrote: post #8
Filligree wrote: post #6

Earlier quoted context omitted.

As a near-fanatic NixOS user (now!), I agree with both you and GP. The learning curve is brutal, so it took me a while to get started, but it's paid off several times over. It's unfortunate that humans can't trust each other enough that saying "You'll like it after a few months" is good enough, but it's also an inevitable fact of life; for starters, the speaker might be mistaken. I don't think NixOS is for everyone,…

Would you suggest the Nix Pills series now? I notice it's 2 years old.

The Nix language hasn't really changed, so sure. Note that it doesn't say much about NixOS.

Re: Reflections on NixOS

#15

Post by akavel »

zeendo wrote: post #8
Filligree wrote: post #6

Earlier quoted context omitted.

As a near-fanatic NixOS user (now!), I agree with both you and GP. The learning curve is brutal, so it took me a while to get started, but it's paid off several times over. It's unfortunate that humans can't trust each other enough that saying "You'll like it after a few months" is good enough, but it's also an inevitable fact of life; for starters, the speaker might be mistaken. I don't think NixOS is for everyone,…

Would you suggest the Nix Pills series now? I notice it's 2 years old.

As a "common user", I'd say very much yes. It goes quite deep into the internals, and touches underlying ideas and basic mechanisms of Nix, which I don't think are expected to change [ever].

That said, note that it starts to be relevant when you're starting to write Nix expressions (meaning, write something in Nix language). Sometimes also when you want to read them and understand them. Which... is probably quite soon after starting to use Nix/NixOS, if you'll want to tweak some configs or add custom new packages. If you're really, really just doing first steps with Nix/NixOS, and/or just use the default packages with only simple tweaks, I'd say you don't need to read it yet (I personally wouldn't grasp enough basics then to understand WTF the articles are talking about at that point).

Re: Reflections on NixOS

#16

Post by mbrock »

I use NixOS since last spring and I adore it so much that I almost credit it with making me like computers again.

It's a kind of bumpy ride sometimes but for me there's no other distribution that's even close. Packaging the Nix way does require patching upstream and that's probably inevitable.

It would be nice to help with the documentation situation, though I'd note that the NixOS manual and the Nixpkgs manual are seriously helpful and quite comprehensive; it's just that there's another type of guide that would really help.

Re: Reflections on NixOS

#17

Post by lil1729 »

I used nixos for a few weeks and then went back to Debian.

* I share the concern of the author on symlinks farm. It is scary! I would like it to be dealt with in the filesystem layer (Plan 9 had a snapshot based filesystem - fossil - years ago). Symlinks have all sorts of weird semantics on different Unix machines.

* Another of my gripe with nixos is that it makes Unix, a single user machine! Sure, packages need not be installed in a user-local way. I may be ignorant of other possibilities here.

* More care for licenses. I still use Debian because they really care for licenses. Last I looked, nixos was in no way close to Debian in terms of documenting the various copyrights and licenses of files pertaining to a package.

Otherwise, Nixos is a great idea and a huge step forward.

Re: Reflections on NixOS

#18

Post by mbrock »

chriswarbo wrote: post #11
haarts wrote: post #4

Earlier quoted context omitted.

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…

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.

Re: Reflections on NixOS

#19

Post by chriswarbo »

bennofs wrote: post #10
chriswarbo wrote: post #2

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 "ni…

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…

> `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 :)

Re: Reflections on NixOS

#20

Post by teh »

lil1729 wrote: post #17

I used nixos for a few weeks and then went back to Debian. * I share the concern of the author on symlinks farm. It is scary! I would like it to be dealt with in the filesystem layer (Plan 9 had a snapshot based filesystem - fossil - years ago). Symlinks have all sorts of weird semantics on different Unix machines. * Another of my gripe with nixos is that it makes Unix, a single user machine! Sure, packages need not…

> Symlinks have all sorts of weird semantics on different Unix machines.

Is there any other implementation than posix in the wild these days?

Post reply on HN