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

Devenv.sh: Fast and reproducible developer environments using Nix

devenv.sh

Post reply on HN
Print view View original

131–140 of 171 posts

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

#131

Post by avidphantasm »

Going to ask a naive and possibly lazy question. On macOS does this replace Homebrew and MacPorts? I used to use MacPorts, now Homebrew. However, I’m thinking of switching back to MacPorts due to how painful using prior package versions is in Homebrew; sometimes I can’t run bleeding edge versions, and Homebrew’s all or nothing approach to versions isn’t working for me anymore.

I use Python with a few key native packages that are a pain to build myself (NumPy, GDAL primarily). Should I be considering Nix instead of MacPorts?

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

#132

Post by dzikimarian »

colinsane wrote: post #27

this, devbox, and others seem to be alternatives to `nix-env shell` or the flake-based `nix develop`. spurred i think by a desire for better UX. these are excellent for any project off-the-ground enough that you’ve run `git init` or created a repo. the adjacent area i’m struggling with is the “i want to write a tiny program to verify some conjecture, and i’ll probably throw it away an hour from now”. think codegolf c…

What I typically do is `docker run -v $PWD:/app python bash`.

Sometimes I've own image with basic dependencies that I like.

Honest question - do these Nix based tools offer more than that?

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

#133

Post by plq »

We are using Gentoo Prefix [1] project to set up our development environment on linux. Containers etc. aren't needed as long as the elf interpreter path and rpath are set up correctly when linking the executable (or with patchelf afterwards).

Highly recommended.

[1]: https://wiki.gentoo.org/wiki/Project:Prefix

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

#134

Post by mikepurvis »

pxc wrote: post #102
methyl wrote: post #95

Earlier quoted context omitted.

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

Based on the amount of patching and such that is necessary in many packages, plus the constraint of not linking two different versions of libXYZ into your final binary, I'd expect it would be pretty hard to have a truly unified environment of multiple nixpkgs pins, at least without a facility for maintaining another big patching layer.

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

#135

Post by rkangel »

domenkozar wrote: post #34

Hi all, I'm the author of https://devenv.sh , https://cachix.org and https://nix.dev . I've been part of the Nix community for more than 10 years and in the last 4 years focused on making it documented, simple and accessible for any developer. After building Cachix (where you can store any software binaries with a few steps) we realized that there needs to be an intuitive interface for crafting developer environments…

Do you have a story for how this works with CI? I have a few projects that use a shell.nix to provide my dev environment, then in CI I just do:

    image: nixos/nix:latest

    before_script:
      - nix-env -f shell.nix -i -A buildInputs
This then gives me a CI environment that perfectly matches my dev environment at all times. Some similar story for devenv would be great.

Of course I'm not sure how that would work - one of the things that interests me with devenv over 'vanilla' nix is your approach to processes which doesn't map so well in the scenario I've described.

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

#136

Post by Keyframe »

pxc wrote: post #109
Keyframe wrote: post #76

Earlier quoted context omitted.

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…

Thank you for the write-up!

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

#137

Post by ArmandGrillet »

avidphantasm wrote: post #131

Going to ask a naive and possibly lazy question. On macOS does this replace Homebrew and MacPorts? I used to use MacPorts, now Homebrew. However, I’m thinking of switching back to MacPorts due to how painful using prior package versions is in Homebrew; sometimes I can’t run bleeding edge versions, and Homebrew’s all or nothing approach to versions isn’t working for me anymore. I use Python with a few key native packa…

> On macOS does this replace Homebrew and MacPorts?

I use Homebrew for casks and the few CLI tools I need for all my projects (e.g. the Github CLI tool) and I use Nix for CLI tools I need to work on a specific repository using specific versions (e.g. node).

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

#138

Post by ghostwriter »

InvaderFizz wrote: post #70
ghostwriter wrote: post #64

Earlier quoted context omitted.

how does it enforce FS and network isolation?

It doesn't. Nix is basically a whole load of compiled dependencies pathed to /nix/hash/dependency So you can have things that would ordinarily be dependency hell running side by side because foo that requires bar6 is compiled against that, and baz that requires bar7 is linked against that. Both versions of bar are present in the nix structure, on a specific path that the software is compiled against.

How do you mean it doesn't if the manual itself says that: "In addition, on Linux, builds run in private PID, mount, network, IPC and UTS namespaces to isolate them from other processes in the system"?

https://nixos.org/manual/nix/stable/command-ref/conf-file.ht...

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

#139

Post by rgoulter »

rkangel wrote: post #135
domenkozar wrote: post #34

Hi all, I'm the author of https://devenv.sh , https://cachix.org and https://nix.dev . I've been part of the Nix community for more than 10 years and in the last 4 years focused on making it documented, simple and accessible for any developer. After building Cachix (where you can store any software binaries with a few steps) we realized that there needs to be an intuitive interface for crafting developer environments…

Do you have a story for how this works with CI? I have a few projects that use a shell.nix to provide my dev environment, then in CI I just do: image: nixos/nix:latest before_script: - nix-env -f shell.nix -i -A buildInputs This then gives me a CI environment that perfectly matches my dev environment at all times. Some similar story for devenv would be great. Of course I'm not sure how that would work - one of the th…

You can see how it's used in the GitHub actions of devenv:

It calls `devenv ci` (which checks that the devenv file is good), then runs a 'script' in the devenv file... https://github.com/cachix/devenv/blob/8bea91cd1073b0d51cf96e...

The 'script' in the devenv file: https://github.com/cachix/devenv/blob/8bea91cd1073b0d51cf96e...

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

#140

Post by callahad »

ghostwriter wrote: post #138
InvaderFizz wrote: post #70

Earlier quoted context omitted.

It doesn't. Nix is basically a whole load of compiled dependencies pathed to /nix/hash/dependency So you can have things that would ordinarily be dependency hell running side by side because foo that requires bar6 is compiled against that, and baz that requires bar7 is linked against that. Both versions of bar are present in the nix structure, on a specific path that the software is compiled against.

How do you mean it doesn't if the manual itself says that: "In addition, on Linux, builds run in private PID, mount, network, IPC and UTS namespaces to isolate them from other processes in the system"? https://nixos.org/manual/nix/stable/command-ref/conf-file.ht...

"Builds" is the operative word there: that specific isolation is optional and only applies during compilation.
Post reply on HN