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

61–70 of 171 posts

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

#61

Post by ar_lan »

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 the strong selling points are here over what is already available.

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

#62

Post by thejosh »

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…

asdf was the closest to this, but the startup time is pretty bad (there is a 300ms+ delay) for apps. It is a giant hack but works well. But I hear about weird dependency issues all the time with Macs (both Intel and the newer Apple Silicon) with Erlang or Elixir.

I'm really excited for nix as true sandboxing would be great. Nix however I couldn't get working properly.. and I've been using Linux for almost 17 years.

Once the UX gets sorted, this is a game changer.

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

#63

Post by aidenn0 »

haolez wrote: post #44
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 use NixOS? I've found it a little too clunky for my taste, as a Gentoo Linux user. But maybe Nix is still worthwhile for me as a standalone tool.

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

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

#64

Post by ghostwriter »

callahad wrote: post #7
judge2020 wrote: post #5

Earlier quoted context omitted.

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.

I believe you are mistaken; Nix has no intrinsic connection to cgroups / containers.

how does it enforce FS and network isolation?

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

#65

Post by [deleted] »

nordsieck wrote: post #39
ruuda wrote: post #37

Earlier quoted context omitted.

One difference is that Docker containers use a separate file system isolated from the host, so you have to separately install your editor/shell in there, mount/clone your dotfiles, etc. With a Nix-based development environment, it can add/override the tools you need, but you get to keep your shell customizations, editor config, etc. Also reproducibility; it can be achieved with containers if you save the artifact (th…

> One difference is that Docker containers use a separate file system isolated from the host, so you have to separately install your editor/shell in there, mount/clone your dotfiles, etc. Can't you just mount a volume from your host machine? Then you can use your regular editor, and just run commands from inside the container.

[deleted]

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

#66

Post by rgoulter »

nordsieck wrote: post #39
ruuda wrote: post #37

Earlier quoted context omitted.

One difference is that Docker containers use a separate file system isolated from the host, so you have to separately install your editor/shell in there, mount/clone your dotfiles, etc. With a Nix-based development environment, it can add/override the tools you need, but you get to keep your shell customizations, editor config, etc. Also reproducibility; it can be achieved with containers if you save the artifact (th…

> One difference is that Docker containers use a separate file system isolated from the host, so you have to separately install your editor/shell in there, mount/clone your dotfiles, etc. Can't you just mount a volume from your host machine? Then you can use your regular editor, and just run commands from inside the container.

While it is possible to work with containers to run programs with files on the host, it's just much more convenient to be able to run programs without dealing with mounting issues.

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

#67

Post by ghostwriter »

wg0 wrote: post #57
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.

Don't know why it is downvoted but isn't it a legitimate concern that if dev and prod environments are produced differently with different tool chains, it might result in discrepancies? Concrete example, dev environment with nix but production is Dockerfile with apt getting packages? Thoughts?

That question never stopped developers from getting Apple hardware and OSX at their workplaces and it seems they've been productive, even though hardly anyone except mobile developers deploy anything on OSX. Besides, what's the point of having a production environment based on apt if it can be derived from the same graph of all dependencies that you use for building and running your software locally by Nix? [1] There isn't need for apt-based images if you've been utilizing Nix already.

[1] https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerToo...

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

#68

Post by v3ss0n »

stefanha wrote: post #15

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

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

#70

Post by InvaderFizz »

ghostwriter wrote: post #64
callahad wrote: post #7

Earlier quoted context omitted.

I believe you are mistaken; Nix has no intrinsic connection to cgroups / containers.

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.

Post reply on HN