Live data from Hacker News

Devenv.sh: Fast and reproducible developer environments using Nix

devenv.sh

121–130 of 171 posts

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

#121
post #44

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 to be a Gentoo user until about 2013: https://domenkozar.com/2013/07/20/9-years-of-linux-distribut...

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

#122

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…

That's the goal of languages.python.enable knob you can turn on.

There are kind of three levels of language support in devenv:

1) Basic tooling + system dependencies, this allows you to use native language package manager and provide system deps to make sure they build.

2) Compiler/interpreter versioning: pick any version of the tooling as you need

3) Full automatic translation of the language tooling into a Nix expressions for the project. This allows you to get all the benefits of what Nix has to offer. This is the most work for each language but the benefits are enormous.

devenv.sh plans to achieve that step by step :)

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

#123
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...

That's something that still needs to be supported and I'll be working on it next week as part of the https://oceansprint.org

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

#125

Earlier quoted context omitted.

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

> 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.

Nix runs on Windows exactly like Docker runs on Windows— only inside a Linux VM. If you ship a Linux VM on Mac or Windows like people usually do for Docker, you're free to run the Linux version of a Nix package on those platforms.

> 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

Nix-Darwin doesn't do anything for packaging issues, it just offers an alternative module system for declaratively managing services and configurations in a NixOS-like way.

Docker containers also don't normally do any kind of service management, they're single-process images. They're not really comparable to orchestrated services managed by NixOS or Nix-Darwin modules. But if your concern is just shipping the same thing and you don't care about what's managing the services, a whole NixOS VM isn't any less efficient than some other VM in which you run `docker-compose` or Kubernetes.

That said, there are Nix-y ways to ship one or more supervised processes in a way that's portable across the platforms that Nix supports. One way is with a manually tailored supervisord config with a nix-shell or something like devenv.sh. Another strategy would be to leverage something an abstraction layer like this one: https://github.com/svanderburg/nix-processmgmt

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

#126

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…

Does devenv uses flakes underneath?

Also, it's called devenv.sh, but.. is it written in shell script?

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

#127

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…

No post body was provided.

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

#128

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…

How do things that aren't NixOS packages interact with this? E.g. if I want a Python package that I can install with pip, or acquire in some other way, that isn't in NixOS's packages.

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

#129
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.

This is what the last paragraph was intended to convey. The tool should be aimed at setting up any environment, not just development.

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

#130
post #57

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?

> Concrete example, dev environment with nix but production is Dockerfile with apt getting packages?

> Thoughts?

Canonical answer is to use Nix to generate the image that goes out to prod as well, based on the same versions used in your devenv.

Post reply on HN