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

Nix is the ultimate DevOps toolkit

tech.channable.com

Post reply on HN
Print view View original

121–130 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#121

Post by throwaway894345 »

Shoue wrote: post #59
jpe90 wrote: post #51

I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them with "nix-env -u" as instructed in the official documentation: https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt This ended up breaking the entire install. After a few hours of troubleshooting I found that the reason it broke was that it updated itself…

I wish Nix would just get rid of nix-env. It's not the way it's meant to be used, you should be using "nix run" or nix-shell for temporary usage, and home-manager for dotfiles and user dependencies. Using Nix like an imperative package manager is not really an improvement over existing ones, the declarative bit is where it truly shines.

I agree, but I think nix-env is only the tip of the iceberg with respect to bad upfront experiences. If you try to make a Go package, for example, you end up having to provide a hash. To generate the hash `vendorSha256`, you have to run `nix-prefetch`, but that program is broken on MacOS. I mentioned elsewhere that I spent a weekend working with the Nix discord to try to install VS Code with some extensions for Rust development, and we collectively couldn't figure it out (I'm not using NixOS, but just Nix the package manager). In the past I've tried to package a simple Python app thinking it would be a simple reference to a pypi package, and I ended up having to package a never-ending matrix of the most obscure C dependencies and ultimately gave up. Maybe if I were doing Haskell development I might find the Nix happy path, but for now I just have a nix shell that installs a few basic CLI utilities and that's the only way I've managed to use Nix successfully. Further, any time I have to do anything in nixpkgs, I find that everything is a slog--since there are so few imports (and because the Nix people don't believe in documentation or types or even sane file/directory organization), in order to find the "shape" of argument `foo` to the Nix package function `Bar`, I need to grep the whole nixpkgs repo for something that uses `Bar` and then figure out what it's passing in for the `foo` parameter. Often `Bar` is passed to several other functions (defined in several other files) before it's called and the thing that gets passed in for the `foo` parameter might be the return value of a function which itself is returning the result of some other function (each of which is defined in other files), etc. This results in a combinatorial explosion of inefficiently grepping around the codebase just to get the type of a symbol (something that would come for free in a statically typed language).

I'm a big believer in the Nix approach to builds, and that this approach holds a lot of potential for DevOps (especially CI/CD); however, there are so many practical problems with Nix and the community doesn't seem especially interested in fixing them. Of course, what volunteers spend their time on is there prerogative, I could volunteer my time rather than criticize, shame on me, etc but it's a loss for the broader world. Personally I would really like to see a community with the ethos of the Rust community pick up the torch and try to build something inspired by Nix, but perhaps with more pragmatic choices (e.g., instead of inventing an obscure scripting language, they might use something more familiar and thus easier on new users; rather than the chaos of nixpkgs, they might give users a type system and/or good editor tooling; rather than the difficult-to-Google "Nix" label, they might pick something a bit less overloaded; etc).

Re: Nix is the ultimate DevOps toolkit

#122

Post by kaba0 »

oblio wrote: post #95
domenkozar wrote: post #64

Earlier quoted context omitted.

That's another problem of documentation. The correct way is to search for packages as the following: https://nix.dev/tutorials/ad-hoc-developer-environments.html... And then install via: nix-env -iA attribute-name New Nix CLI as part of next release fixes that, but it's not out yet.

Now, don't get me wrong, I don't have a horse in this race. But as a complete outsider, this doesn't fill me with confidence. If Wikipedia is to be believed, NixOS was launched in 2003, so 18 (!) years ago, I assume that's when Nix was created. The issue mentioned seems quite basic and you're replying that it will be fixed in a new Nix CLI. This seems like a basic QA fail, I wouldn't want anything like this within 10…

But it works as expected by someone understanding the underlying system, and some existing advanced users do use it. Backward compatibility is important already.

It’s not like you have found a bug in the way the fundamental package handling is done which hasn’t been fixed for a long time, so I don’t think it’s fair, especially over an in context negligible nitpick.

Re: Nix is the ultimate DevOps toolkit

#123

Post by oblio »

catern wrote: post #103
oblio wrote: post #95

Earlier quoted context omitted.

Now, don't get me wrong, I don't have a horse in this race. But as a complete outsider, this doesn't fill me with confidence. If Wikipedia is to be believed, NixOS was launched in 2003, so 18 (!) years ago, I assume that's when Nix was created. The issue mentioned seems quite basic and you're replying that it will be fixed in a new Nix CLI. This seems like a basic QA fail, I wouldn't want anything like this within 10…

nix-env (including nix-env -u) is purely a user-facing UI helper for new users. One would never use it in production, or even for development, even when it was first released; it's only ever been for new user onboarding. So it's a bit low priority, since it has no production impact and experienced users don't use it...

Today's new users are tomorrow's experienced users.

I guess it depends on what Nix wants, if it wants to remain a niche system, then things are good as-is.

Though, on the other hand, the comment says a new CLI is close to release, so I guess people are trying to improve things.

Re: Nix is the ultimate DevOps toolkit

#124

Post by kaba0 »

tnzm wrote: post #77
siraben wrote: post #60

Earlier quoted context omitted.

Could you elaborate what you mean by this? Nix has lazy evaluation so as Nixpkgs grows it doesn't perceptibly change how long package installations, building, etc. take.

When I run `nixos-rebuild switch --verbose`, it does seem to go through the entirety of nixpkgs. Especially noticeable on a RPi with its slow I/O.

That’s just evaluation. The next bigger change in nix itself will likely be the ability to better cache evaluations, significantly speeding up this.

Re: Nix is the ultimate DevOps toolkit

#125

Post by domenkozar »

oblio wrote: post #95
domenkozar wrote: post #64

Earlier quoted context omitted.

That's another problem of documentation. The correct way is to search for packages as the following: https://nix.dev/tutorials/ad-hoc-developer-environments.html... And then install via: nix-env -iA attribute-name New Nix CLI as part of next release fixes that, but it's not out yet.

Now, don't get me wrong, I don't have a horse in this race. But as a complete outsider, this doesn't fill me with confidence. If Wikipedia is to be believed, NixOS was launched in 2003, so 18 (!) years ago, I assume that's when Nix was created. The issue mentioned seems quite basic and you're replying that it will be fixed in a new Nix CLI. This seems like a basic QA fail, I wouldn't want anything like this within 10…

I agree with your reasoning and the reason this is hard to change is similar to Python 2->3 transition.

If it was about 50 users, we could just do it.

Since there are many users, it takes a while to move from one UI to another.

Re: Nix is the ultimate DevOps toolkit

#126

Post by otabdeveloper4 »

chaorace wrote: post #66
Shoue wrote: post #59

Earlier quoted context omitted.

I wish Nix would just get rid of nix-env. It's not the way it's meant to be used, you should be using "nix run" or nix-shell for temporary usage, and home-manager for dotfiles and user dependencies. Using Nix like an imperative package manager is not really an improvement over existing ones, the declarative bit is where it truly shines.

Agreed, but perhaps they should officially adopt home-manager then? It felt strange to me that the best way to be using nix was a separate community project.

At the moment the happy path for Nix is using it in the same space that Docker is used now - for providing reproducible dev/prod environments for server backends. (And in fact Docker and Nix complement and play nice with each other.)

You could theoretically use Nix for managing user apps too, but that's a niche use case and (as you found out) not in a working state.

Re: Nix is the ultimate DevOps toolkit

#127

Post by rkrzr »

throwaway894345 wrote: post #121
Shoue wrote: post #59

Earlier quoted context omitted.

I wish Nix would just get rid of nix-env. It's not the way it's meant to be used, you should be using "nix run" or nix-shell for temporary usage, and home-manager for dotfiles and user dependencies. Using Nix like an imperative package manager is not really an improvement over existing ones, the declarative bit is where it truly shines.

I agree, but I think nix-env is only the tip of the iceberg with respect to bad upfront experiences. If you try to make a Go package, for example, you end up having to provide a hash. To generate the hash `vendorSha256`, you have to run `nix-prefetch`, but that program is broken on MacOS. I mentioned elsewhere that I spent a weekend working with the Nix discord to try to install VS Code with some extensions for Rust…

(author here) I agree that Nix not being statically typed is one of the biggest drawbacks of the language. Having it statically typed with a strong type system like Haskell's would help solve some of the readability issues that you mention. Types of course also serve as documentation, which is another often-mentioned weak point of the language. Finally, with static types we could also have much better editor support with nice things like auto-completion.

Unfortunately, I'm not aware of any efforts to add (optional) typing to the Nix language.

Re: Nix is the ultimate DevOps toolkit

#128

Post by carlmr »

supermatt wrote: post #9

I spend a few hours looking at nix about a year ago and found it impenetrable. I simply do not grok the syntax or what the functions do. I tried searching for the functions shown in the examples on the website to no avail. I searched packages, options, and even resorted to ctrl-f while clicking through the site "documentation"... It sounds awesome, but its in dire need of some better documentation if it wants to be a…

I think not only documentation but a complete UX overhaul.

The examples you find for creating a shell.nix usually work individually, but if you need a combination of two nix files there seem to be too many ways to do things, because I find it almost always impossible to combine two examples into one.

Also for searching packages I always end up looking on the website. Using the built-in search you have to do some weird incantations that aren't easy to remember and you still don't get the full list of packages that are related.

It also doesn't help that the package names are random. There's no standard format it seems: gcc 9 is "gcc9" while clang 9 is "clang_9". Why not have packages be .. or any other standard convention.

Then you could also say you want a certain version of a package instead of having a name for each. Or a minimum version.

Maybe we need a wrapper around nix that exposes a user friendly interface. I really like the basic idea.

Re: Nix is the ultimate DevOps toolkit

#129

Post by whateveracct »

microtonal wrote: post #21
candiddevmike wrote: post #17

The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, an…

The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. For me, the big benefit is that even though I have to read the upstream documentation, I can use the same syntax for everything and do not have to learn and use N different configuration file syntaxes.

And when you figure something out, you can abstract over patterns because Nix has functions!

Re: Nix is the ultimate DevOps toolkit

#130

Post by georgyo »

chriswarbo wrote: post #104
georgyo wrote: post #40

Earlier quoted context omitted.

Having used nix for two years now for both work and personal purposes, I agree. Though I have also come to think nix is doing things in much better ways than AppImage, Docker, Snap, Flatpack, and others. I won't focus on the good parts, but focus on your comment. Nix has three things that I think are confusing and took me an embarrassing long time to grok, and I find other people confused by as well. 1. Where does th…

> Bonus 4. In nix it is really easy to build single language applications. However if you need to mix two, finding good docs or examples is really hard. IE, if you want to build the javascript front end of your web app as well as the python backend. These combinations need at least two derivations, and how to make it happen is bespoke every time. For anything that doesn't fit a common nixpkgs function (like `buildPyt…

That is a gross oversimplification.

An javascript front end can have thousands of dependencies, and the nix build environment does not have network access unless it's computing a fixed output.

To do that manually would be a nightmare, so you must automated either with tools you write or tools someone else has written.

Then you still have to figure out how to combine it all together.

Also on allowing network access in the sandbox requires elevated privileges which means you cannot do that method on environments you don't have full control. And it would create builds that are likely not reproducible.

Post reply on HN