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

21–30 of 171 posts

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

#21

Post by AceLewis »

carlmr wrote: post #8
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.

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…

You can also not only cache locally but cache nix builds online with services like Cachix. Then you can build a nix env on a powerful dev machine and push to the cache so when the Nix environment is built on a low powered CI machine it can easily download the build instead of trying to build and possibly time out.

Build once on one machine and all developers can just download the build.

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

#22

Post by vidar »

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…

The word you are looking for is staging environment

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

#24

Post by baby »

crabmusket wrote: post #17

Seems like Nix is having a bit of a moment. After devbox[1] was released I started looking into Nix, and there's a lot happening. I'm staying away from these Nix wrappers and learning how to do some basic nix-shell work, myself. Until it's proven the wrappers are adding real value, not just trying to hide scary scary Nix from devs who only feel safe in YAML files. For the curious, this post[2] describes mixing Nix an…

Indeed we’ve had all sorts of issues with nix and mac (and intel mac as well). Especially tooling like vscode, sublime merge, etc.

Oh and I managed to brick nix on my mac, for some reason I can’t even reinstall it. Need to spend more time debugging that.

Didn’t play nice with our Rust dependencies as well I found. At least it seemed unnecessarily complicated to set it up with an already existing Rust project.

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

#25

Post by baby »

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.

Containers are way too slow, and take too much space (they don’t share dependencies). Also doesn’t necessarily play well with tools AND is hard to setup for dev environments (what do you mount?)

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

#26

Post by crabmusket »

yakshaving_jgt wrote: post #19
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…

You don’t want to deploy your development tool chain to your production environment, ergo, you want a development environment.

In the JS world it's common to have hot-reloading development servers, whereas the production environment does not do that. And with the rise of TS, transpilation and bundling are also a thing on the backend, not just for shipping web assets. Once the bundle is done, all your production server needs is `index.js` and `node`, not `tsc`, `webpack` or whatever else you're using.

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

#27

Post by colinsane »

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 competitions, if you can’t relate.

the environments i create for these follow similar patterns. it’s either python with numpy, pandas and plotly, or it’s Rust with clap and serde, say. i’d love a tool where i can just `cd /tmp/my-hourlong-project` and then `devenv python` to get a python shell that’ll have everything i often use (and probably more).

hearing from people who use these tools, nobody has told me that any of these can do this — except that since they crawl up the fs tree looking for their env definition maybe i could just stash some definitions at the fs root and get globally-invokable environments that way. seems hacky though: i’d hope for a method that’s more officially supported.

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

#28

Post by emptysongglass »

sisve wrote: post #12
antoniojtorres wrote: post #3

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

Yes, been using devbox for a while now. It's great. This seems like a direct competitor or? Have anyone compared them?

I much prefer Devbox because it lets Nix be what it's best at without needing a user to know anything at all about its DSL and has a very straightforward on-ramp for even Nix-naive teams. Its easy OCI image creation is icing on the cake for container development.

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

#29

Post by crabmusket »

baby wrote: post #24
crabmusket wrote: post #17

Seems like Nix is having a bit of a moment. After devbox[1] was released I started looking into Nix, and there's a lot happening. I'm staying away from these Nix wrappers and learning how to do some basic nix-shell work, myself. Until it's proven the wrappers are adding real value, not just trying to hide scary scary Nix from devs who only feel safe in YAML files. For the curious, this post[2] describes mixing Nix an…

Indeed we’ve had all sorts of issues with nix and mac (and intel mac as well). Especially tooling like vscode, sublime merge, etc. Oh and I managed to brick nix on my mac, for some reason I can’t even reinstall it. Need to spend more time debugging that. Didn’t play nice with our Rust dependencies as well I found. At least it seemed unnecessarily complicated to set it up with an already existing Rust project.

I should clarify, the issues were with Docker. So far, our M1 devs are able to use Nix fine, though the official installation scripts sometimes don't set the path correctly.

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

#30

Post by stavros »

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…

Why can't you have an alias that's basically:

mkdir /tmp/my-hourlong-project cp ~/my-env-definitions/python.nix /tmp/my-hourlong-project

Is that something like what you mean?

Post reply on HN