[HN Gopher] Devenv.sh: Fast and reproducible developer environme...
___________________________________________________________________
Devenv.sh: Fast and reproducible developer environments using Nix
Author : frankpf
Score : 58 points
Date : 2022-11-18 14:52 UTC (1 days ago)
(HTM) web link (devenv.sh)
(TXT) w3m dump (devenv.sh)
| cphoover wrote:
| 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.
| callahad wrote:
| 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 performance of directly running tools
| without the risk of clashing with systemwide software.
|
| Reproducibility: Nix provides much stronger guarantees about
| the exact versions of software you're running. It effectively
| gives you a lockfile for your _entire_ dependency chain, all
| the way down to libc. Containers tend to be more stateful:
| everyone on your team may be using the same Dockerfile, but if
| you build an image from it two weeks apart, you 're probably
| going to get very different outputs due to things like your
| apt-get update step returning new versions of packages. This
| doesn't happen with Nix.
|
| The beauty is that this isn't either/or; you can actually use
| Nix to generate OCI container images which are actually fully
| specified and repeatable.
| [deleted]
| judge2020 wrote:
| If I'm not mistaken, Nix uses cgroups as well on non-NixOS
| systems, so it is basically containers. You're probably
| thinking about docker as a whole, in which Nix is effectively
| an alternative package manager/distribution system for
| containers.
| mikepurvis wrote:
| It uses some of that stuff to isolate its background build
| sandbox, but none of it affects a normal nix subshell.
| callahad wrote:
| I believe you are mistaken; Nix has no intrinsic connection
| to cgroups / containers.
| [deleted]
| carlmr wrote:
| One thing is perfect caching. Each package is cached in its own
| folder, so if you exchange one package you don't have to
| rebuild the rest of the image.
|
| Also you can have multiple versions of the package cached.
|
| Also all your environments benefit from the cache, since each
| "layer" is independent.
|
| Docker's layer based caching is very limiting for larger
| images. With Nix you spend basically no time on incremental
| builds outside of the time for the one package you changed.
| kuhsaft wrote:
| Though it's like comparing apples and oranges, the primary
| advantage over containers would be performance.
|
| Nix (not to be confused with NixOS) is a package manager. Think
| of it like apt.
|
| Containers on the other hand are (usually) utilizing kernel
| level isolation to run a whole user space starting with PID 1.
| These isolation techniques have overhead.
|
| Since Nix is a user space application, you can run it in a
| container and Nix provides one `nixos/nix`.
| antoniojtorres wrote:
| This looks nice! I'm really enthusiastic about these nix based
| dev env systems. Recently saw devbox[0] here, tried it out and
| fell in love. It's made me very interested in all things Nix!
|
| 0 - https://news.ycombinator.com/item?id=32600821
| sisve wrote:
| Yes, been using devbox for a while now. It's great. This seems
| like a direct competitor or? Have anyone compared them?
| methyl wrote:
| Big drawback of devbox is that you cannot pin packages to
| specific SHA, which is quite a big limitation when it comes
| to versitality. I think you can do that on devenv.sh.
| dloreto wrote:
| The latest version of devbox allows pinning the sha of the
| nixpkgs repository to whatever you want. We don't yet allow
| pinning on a per-package basis within nixpkgs, but we're
| working on that.
| stefanha wrote:
| 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 and development.
___________________________________________________________________
(page generated 2022-11-19 23:00 UTC)