Live data from Hacker News

Nix is the ultimate DevOps toolkit

tech.channable.com

161–170 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#161
post #57

Earlier quoted context omitted.

That's a lot of questions - What is the story in nix for packaging untagged branches of software If you want to do unreleased software, you would create overlays that added them. You're overlays most likely would not need to define the build, just create an override of the one in nixpkgs with a new source: https://discourse.nixos.org/t/how-to-override-package-versio... - Does the nix hash account for dependencies onl…

> Nix only writes new files to a remote store. As such nix caches can be served by anything that can serve files. I personally upload to S3 and have artifactory use that as a remote. What about the maintenance side, though, like being able to clean/reap old builds from the cache, reason about which ones are part of important/supported chains vs throwaway builds from merge pipelines, etc?

Ah, there is no method.

With S3 you can create file lifecycles that will move them to cheaper storage and eventually delete them.

You could potentially create two buckets. One for throw away pipeline builds, and another for when things graduate to something you want to keep.

It wouldn't be very hard to make some tooling, the files in the cache have almost all the metadata you need: http://cache.nixos.org/0ljamf3irbyahd00849b2v1cdddypn8a.nari...

But because it all hashed based, you would need something to read all that into a database. I am unaware of any tooling that does that today.

Re: Nix is the ultimate DevOps toolkit

#162
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…

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.

What an absolute nightmare. Just from reading this one comment thread I will never, ever try this tool. It sounds like there are a thousand ways to achieve a given task and no one can agree which one is "right", but everyone can agree that the way blessed in the official documentation most certainly isn't.

Re: Nix is the ultimate DevOps toolkit

#163
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…

Thanks for the example - I’ve been looking for how to make mix packaging easy.

How do you add files to this build? For example, if I have this program.rb that depends on ruby:

    puts “Hello World”
And then you add a file called package.nix

    let pkgs = import  {}; in
    pkgs.runCommand "my-app"
      {
        buildInputs = [pkgs.ruby];
      }
      ''
      pwd && ls;
      ruby ./program.rb
      ''
How do you get your files in there - like “ADD” in a Dockerfile?

Re: Nix is the ultimate DevOps toolkit

#164

Earlier quoted context omitted.

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…

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. You can also stub the hash (e.g. with lib.fakeSha256 ). nix-build will fail with a hash mismatch and tell you the correct hash. I mentioned elsewhere that I spent a weekend working with the Nix discord to try to install VS Code wit…

> You can also stub the hash (e.g. with lib.fakeSha256). nix-build will fail with a hash mismatch and tell you the correct hash.

Are you kidding me?

Re: Nix is the ultimate DevOps toolkit

#165

Earlier quoted context omitted.

> Nix only writes new files to a remote store. As such nix caches can be served by anything that can serve files. I personally upload to S3 and have artifactory use that as a remote. What about the maintenance side, though, like being able to clean/reap old builds from the cache, reason about which ones are part of important/supported chains vs throwaway builds from merge pipelines, etc?

Ah, there is no method. With S3 you can create file lifecycles that will move them to cheaper storage and eventually delete them. You could potentially create two buckets. One for throw away pipeline builds, and another for when things graduate to something you want to keep. It wouldn't be very hard to make some tooling, the files in the cache have almost all the metadata you need: http://cache.nixos.org/0ljamf3irbya…

Got it. Yeah, bucketing by use-case would really not be that hard, you could have a system for rotating through them. I think Artifactory has some built in capabilities for aliasing, presenting multiple repos as if they are the same one, etc.

In any case, if I rolled my own hash package scheme with debs, I'd have to build this piece of the tooling regardless.

Re: Nix is the ultimate DevOps toolkit

#166
post #59
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.

Eh, I don't think nix-env is all that bad. Put it this way:

nix-shell lets you dip your toes in the water, without learning the Nix language. Amazing value added... but sometimes it's annoying that it forgets that package you used yesterday.

nix-env lets you "install" software, without learning the Nix language. Great, now I can use that Nix package repeatedly without having to nix-shell it. We're still better off than "apt install" at this point, and it's no harder than that.

Everything else -- nixos config, home-manager, flakes, overlays, etc. -- requires Nix language knowledge, and non-superficial comfort level with the Nix data model (nixpkgs, attribute sets, and a very long tail of other things).

Nix-env is a beneficial stepping stone for converting dabblers into diehards, and is one of the Nash equilibria for some Nix users. (i.e., not everyone wants to learn the language and drink the koolaid, they just want to enjoy some additional benefits beyond nix-shell.)

Re: Nix is the ultimate DevOps toolkit

#167

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…

What took me a long time to understand is that there are different types of nix expressions (e.g. nix modules). For a long time I thought they are all the same. I hope nix flakes fixes the situation when they are released/stable.

Re: Nix is the ultimate DevOps toolkit

#168
post #32

Earlier quoted context omitted.

What kind of tutorial would you like to read?

My dream tutorial shows how to move from what I have to the new thing, because that teaches me what new ways of thinking I need to adopt. Like right now at work we have a small team making a website with docker-compose to specify the dev environment, pip-tools to pin python dependencies, and saltstack to deploy new state to bare metal in production. How exactly, command by command, would nix solve the same problems?…

This isn't a tutorial, but for an overview of Nix and Docker read https://sandervanderburg.blogspot.com/2020/07/on-using-nix-a...

Re: Nix is the ultimate DevOps toolkit

#169

Earlier quoted context omitted.

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…

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. You can also stub the hash (e.g. with lib.fakeSha256 ). nix-build will fail with a hash mismatch and tell you the correct hash. I mentioned elsewhere that I spent a weekend working with the Nix discord to try to install VS Code wit…

Thanks for taking the time to respond. It's good to know that there are reasons/workarounds for the various problems, but I hope you understood my main thrust, which is not that this is an exhaustive list of issues with Nix, but rather these are the kinds of issues one can expect to encounter (or perhaps I'm just unusually unlucky) when delving into Nix.

I get the perception that people think Nix is a panacea for common CI/CD problems (and to be clear, I think it could be such a panacea one day) but rather it solves some problems but introduces many more, harder problems--which no doubt individually have workarounds and so on, but finding them probably requires intimate knowledge of Nix and the ecosystem that you're trying to package. Unfortunately, I can live with suboptimal builds and a little nondeterminism/impurity, but I can't be dead-in-the-water because I can't figure out how to package a dependency that my app depends on.

So I'm rooting hard for Nix, but I want to share my experiences so potential users know what they might run into and so any Nix contributors know a bit more what users are running into (if it's not already known).

> I think most of us are interested in fixing problems.

I didn't mean to imply you weren't interested in fixing any problems, but rather the problems that I care about, which have persisted since I tried Nix for the first time circa 2014.

> So, it is quite hard to make fundamental changes to Nix (e.g. typing) and roll them out.

Surely gradual typing would be relatively easy to roll out, as the name implies? Similarly, documentation improvements could be rolled out pretty easily (e.g., put beginners on the happy path, don't recommend nix-env, tell people about homemanager if that's the thing they should be using, etc). I mean these things in the spirit of constructive feedback--if you want to court new users, these seem like low hanging fruit.

> Things are happening, e.g. flakes provide a standard interface to package sets, there is work on supporting content-adressed outputs (outside fixed-output derivations), but with the size of the Nix ecosystem, these things take a long time to crystallize and roll out.

I'm glad to hear things are moving--I'll need to read up on content-addressed output and flakes!

Re: Nix is the ultimate DevOps toolkit

#170

Earlier quoted context omitted.

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

Thanks for the example - I’ve been looking for how to make mix packaging easy. How do you add files to this build? For example, if I have this program.rb that depends on ruby: puts “Hello World” And then you add a file called package.nix let pkgs = import {}; in pkgs.runCommand "my-app" { buildInputs = [pkgs.ruby]; } '' pwd && ls; ruby ./program.rb '' How do you get your files in there - like “ADD” in a Dockerfile?

example in the manual: https://nixos.org/manual/nixpkgs/stable/#chap-trivial-builde... shows how it creates a file `$out/message`.

If you want to write to nix store with stdenv use $out.

Post reply on HN