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

91–100 of 171 posts

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

#91

Post by [deleted] »

callahad wrote: post #11
cphoover wrote: 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…

[deleted]

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

#92

Post by indemnity »

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…

Looks great, looking forward to trying it out.

I've been mentioning to a work colleague that someone needs to do for the somewhat baroque Nix tools and concepts what Docker did for containers.

It just needs a nice porcelain over the top that provides some consistent CLI UX, but lets you dive down deeper as you get more comfortable with the system.

As someone who just two weeks ago got into Nix/NixOS via this repo[1] from mitchellh, one thing I'd love:

A nice, seamless way to remote connect JetBrains IDEs or VS Code into the environment.

I tried the VS Code server, but had some problems getting it going on ARM Linux (my machine is an M1 Mac, and I'm running nixOS inside an arm64 VM).

I have been surviving on NeoVIM, but really would like to use the editors/IDEs I am used to.

Something like starting up the JetBrains Fleet/Gateway kind of thing, or VS Code server, when entering an env, so that I can connect the IDE to the environment, and it has access to everything in that environment.

Since I don't see me convincing the 20+ people in my team to switch to VIM :)

[1] https://github.com/mitchellh/nixos-config

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

#93

Post by colordrops »

Keyframe wrote: post #76
aidenn0 wrote: 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 used Ubuntu for 8 years and switched about 10 months ago and never going back. Ubuntu feels primitive like VAX or TRS80 in comparison.

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

#94

Post by colordrops »

1letterunixname wrote: post #87

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.

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

#95

Post by methyl »

mikepurvis wrote: post #60
pxc wrote: post #41

Earlier quoted context omitted.

> We don't yet allow pinning on a per-package basis within nixpkgs, but we're working on that. Where can I view that work? That's a feature the whole Nix ecosystem could benefit from. Is there an RFC for Nixpkgs to change the policy on versioning, or is this an effort to rig up some kind of frontend for an index that lets you pull package recipes from different versions of Nixpkgs?

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.

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

#96

Post by airocker »

callahad wrote: post #89
airocker wrote: post #82

Earlier quoted context omitted.

So it does plan to replace all up streams eventually including apt, npm, pypi, gem etc by providing the ability to build and configure all software? I am not understanding this, currently the original maintainers release on their own stores. the build and configure steps may change over time. Unless the original maintainers start building for nix, would not this be too hard to maintain?

> the build and configure steps may change over time. Unless the original maintainers start building for nix, would not this be too hard to maintain? This is indeed very hard, but Nix's deep locking makes this a tractable problem: if a version of a package builds once, it will keep building for as long as the source code is available. So in some ways, this Nix has an easier job compared to traditional distribution me…

but new versions may need new steps to build?

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

#97

Post by iopq »

airocker wrote: post #43

I think it is an overkill to have your dev environment different from your deploy environments. This would mean you maintain dev environments separately than deploy environments. It would mean you are debugging something other than you are testing and deploying. About reproducibility, unless nix promises to fix all upstreams (apt, pypi ??), I don't see how it can fix reproducibility on the client side only.

You're right, we should work on everyone using NixOS, that way dev and deploy is the same :)

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

#98

Post by mongol »

ar_lan wrote: post #61
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…

I hope this doesn't come off critical - but what does this offer over a flakes-based `devShell` with `nix develop`? The two things that stand out that maybe look slightly easier are the processes section, and the pre-commit hooks sections - but from what I can tell these are generally all solveable via native flakes. Just curious - if this is a valuable tool to add to the arsenal, I'm all for it, but I'm curious what…

This I wonder too. I have not yet dived into this part of the nix ecosystem so I can't tell the differences but it looks superficially similar. It would be good if the main differences could be explained.

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

#100

Post by pxc »

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.

To summarize this in a metaphor:

Nix 'isolates' packages by ensuring that they do not know where to look for each other, rather than ensuring that they cannot possibly see each other.

In addition to the example given by the parent poster, here are some other steps taken towards that end in the Nix ecosystem:

Nix-built programs look for their libs, they don't see libs other than what they were built with because each package has its own little FHS-shaped tree, which it thinks of in the way a 'normal' package might think of as 'the system'— that thing which has a `/usr/lib` in which to find libraries and a `/etc` in which to find config files and a `/usr/share` in which to find assets, etc.

In addition to linking against hardcoded full paths to dependencies, outlined above, maintainers also take steps to ensure that, e.g., external programs referenced in shell scripts in a Nix package also refer to full paths into the Nix store.

Post reply on HN