Live data from Hacker News

Devenv.sh: Fast and reproducible developer environments using Nix

devenv.sh

101–110 of 171 posts

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#101
post #2

Can someone explain to me the advantage of using Nix over containers? What do they offer that are not provided with using docker or other container platform.

Strictly compared to containers, the big advantages are reproducibility and lower overhead. Overhead: Windows and macOS can't run Linux-based containers natively. Instead, there's always a full Linux virtual machine running in the background acting as an intermediary and host for your containers. Nix can conjure arbitrary native development environments on a per-command or per-terminal basis, giving you all the perfo…

Adding to this, my understanding is that Nix does not guarantee any Nix derivation/package will seamlessly run on Linux, Mac, and Windows. So in this one aspect it is less capable than Docker, i.m.h.o.

i.e. if a package depends on the systemd package https://search.nixos.org/packages?channel=unstable&show=syst... , Nix will not automatically find a replacement to run the package on Mac. But it may be possible to manually work around this with https://github.com/LnL7/nix-darwin

More on building Docker images with Nix: https://nix.dev/tutorials/building-and-running-docker-images

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#102
post #95

Earlier quoted context omitted.

From experience just maintaining a private 1000+ package overlay to nixpkgs, this sounds super fraught, at least for any of the scenarios most typically interesting to developers, like wanting a backport of some library version that just landed to your otherwise-stable months old pin of nixpkgs. For a lot of the most important ones, though, nixpkgs already maintains multiple recent versions, though— fifteen boosts in…

Yeah I found it odd that there is no first class feature for versioning. I wonder what’s the reason, since it’s a pretty obvious need for a package manager.

> Yeah I found it odd that there is no first class feature for versioning. I wonder what’s the reason, since it’s a pretty obvious need for a package manager.

Binary package managers need a first-class notion of versioning for install-time dependency resolution, Nix doesn't actually perform install-time dependency resolution.

Nixpkgs is a monorepo, and thanks to the way it supports side-by-side installations of conflicting versions, instead of using version numbers to check/assert compatibility, Nix just ships each package with exactly the dependencies it was built with, all the way down the dependency closure.

While it doesn't retain that fixity all the way down the dependency chain in the case of 'partial upgrades', this is also how Homebrew works. Gentoo Portage does include some functionality for reasoning about version constraints. (I'm not sure about other source-based package management systems like Ravenports or FreeBSD Ports or MacPorts.)

If Nixpkgs (or a counterpart, like an archive repo) included not just the 'current' set of combinations but a collection of old build recipes along with a record of version numbers for which builds had been successful with that recipe, or a range of versions that were known/expected to work... that could be really useful for projects downstream in the Nix ecosystem. It could power tools that import or generate Nix code given some packages and version constraints. But it's not actually needed in order for Nix to match the practical functionality of best-in-class binary package management systems like dnf.

There actually are already some tools in the Nix ecosystem that use (indices of?) old copies of Nixpkgs as this kind of archive: mach-nix comes to mind! Idr if it uses them at a source level for creating new build definitions or if it actually uses the whole dependency tree, embedded in those old versions of Nixpkgs. Either way, a better version of that is what I think Nixpkgs could soundly facilitate, while still only maintaining a single combination of packages as the official, coherent, cached collection for use by end users.

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#103

The only way to get reproducible environments is to have an immutable base OS with packages compiled without environment, library, or fs leaks. In the real world, this requires lots of patching and isolation (hypervisor and/or containers). Unfortunately, Nix suffers the fate of Haskell: so powerful that the masses can't and don't use it. By contrast, Homebrew spreads like cancer. "Worse is better".

Plenty of us are using it. But it would be great if it were more mainstream, yes.

wishful thinking. nix is not mainstream

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#104
This looks interesting but it seems that if you're wanting to use specific versions of two separate packages, that are not in the same nixpkgs commit, you're a bit out of luck. For example, if I want to use an older version of Terraform with a newer version of the Terraform AzureRM provider, I couldn't quite figure out a way to do it...

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#105
post #104

This looks interesting but it seems that if you're wanting to use specific versions of two separate packages, that are not in the same nixpkgs commit, you're a bit out of luck. For example, if I want to use an older version of Terraform with a newer version of the Terraform AzureRM provider, I couldn't quite figure out a way to do it...

And isolated GUI apps would be also nice to have

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#106
post #59

I avoid "developer environments" because they are different from production environments and that leads to bugs that don't show until the application is in production. "But it worked in development" problems waste a lot of time. Putting "developer environment" in the name of this tool perpetuates bad practices. Any tool that constructs environments for applications should be general enough to handle both production a…

Why not use Nix in production, then? Hermetic evaluation of all dependencies allows a deterministic dev/prod set of environments. I, at the very least, completely disagree with you on this specific point as this tool is using Nix.

[deleted]

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#107
post #63

Earlier quoted context omitted.

I used Gentoo for over 15 years before switching to NixOS. I like it so much better, I'm never going back.

How about someone from let's say Ubuntu/Debian or Fedora?

Coming originally from Fedora, anything non-declarative (like NixOS or Guix) feels incredibly clunky for servers. There is an incredible value in writing a server configuration once that is fully reproducible and results in systems that don't have drift.

For desktops there is that value as well. However, I have usually set up my macOS environment in two hours or so, the pay-off is a bit less for me. However, setting up a dev environment for development projects is awesome, especially if a project has dependencies that are normally considered system dependencies (e.g. native libraries).

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#108
> Anything about Nix > fast

Massive doubt.jpeg, as all my previous attempts at understanding and using Nix have all been "trust me bro, THIS random github repo source code has the Current Best Practice (already outdated)" and various other random two article blogs on how great nix is.

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#109
post #63

Earlier quoted context omitted.

I used Gentoo for over 15 years before switching to NixOS. I like it so much better, I'm never going back.

How about someone from let's say Ubuntu/Debian or Fedora?

I ran Gentoo for a few years, but the distros I used most in the years immediately before discovering NixOS were (based on) openSUSE, Arch, and Ubuntu.

NixOS is more similar, culturally (rather than technically), to Debian than it is to Ubuntu or Fedora, both in the sense that it's not backed by a large corporation and also in the sense that it doesn't promote a particular vision of the Linux desktop.

On a technical level, its package management approach will feel like a larger paradigmatic leap, coming from a Fedora or an Ubuntu, than it would from a Gentoo. NixOS doesn't have quite the same notion of a repository as either of the former. The concept of 'overlays', used to extend Nixpkgs, would be familiar to a Gentoo user but not a Fedora user.

That said, an Ubuntu user won't notice a lot of compilation from source, and in fact they'll likely find Nix pretty fast as a package manager. And likewise, NixOS is more different from any of those than it is similar to Gentoo.

An Ubuntu user switching to NixOS will likely be

  - impressed with the wide selection of packages
  - happy with how easy it is to iterate on a config
  - delighted by the rollbacks
  - pleased with how easy it is to add most software to Nixpkgs
  - eventually frustrated by the inflexibility of having to package things for Nix to get them to work well on NixOS
  - appreciative that their system doesn't accrue cruft over time
  - perplexed with having to learn slightly different processes for packaging things in different language ecosystems in Nixpkgs
  - blown away by the knowledgeable and helpful community
depending on how deep they go with NixOS. Overall, I can't say if you'll like the whole declarative paradigm or not, which will be the biggest difference. But bear in mind that you can enjoy many of the benefits of Nix while still keeping one foot 'in both worlds', by using Nix on top of Ubuntu or Fedora rather than jumping in with NixOS.

Jumping right in with NixOS is a good idea if

  - your needs are simple, or
  - you have a bit of packaging experience (for any distro), or
  - you have an interest in functional programming, or
  - you like learning new things, or
  - the reproducibility and uniform management of your system's configuration is highly appealing to you.
If you have less Linux experience, or you feel less inclined to commit to the whole paradigm for any reason, try giving yourself a taste of Nix and NixOS' declarative style by running Nix and Home Manager on top of your existing distro of choice! I think NixOS is in a mature enough state that there's just a ton of functionality and packages in it, and lots of Linux users could be happy with it as-is. But for those who are thinking about getting into extending it and molding it to fit their own needs but aren't sure about the hairy details of that kind of work, running Nix on foreign Linux can be a good, noncommittal way to get a sense of what that work looks like.

On the whole, I think any experienced Linux user will at least find it interesting. But the more common response from those who really get a handle of it is 'I could never go back'.

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#110
post #68

I avoid "developer environments" because they are different from production environments and that leads to bugs that don't show until the application is in production. "But it worked in development" problems waste a lot of time. Putting "developer environment" in the name of this tool perpetuates bad practices. Any tool that constructs environments for applications should be general enough to handle both production a…

Fine, let's just develop on production. Cases solved

Good idea. Let’s go beyond merely testing in prod
Post reply on HN