Live data from Hacker News

Devenv.sh: Fast and reproducible developer environments using Nix

devenv.sh

41–50 of 171 posts

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

#41
post #14
post #13

Earlier quoted context omitted.

Big drawback of devbox is that you cannot pin packages to specific SHA, which is quite a big limitation when it comes to versitality. I think you can do that on devenv.sh.

The latest version of devbox allows pinning the sha of the nixpkgs repository to whatever you want. We don't yet allow pinning on a per-package basis within nixpkgs, but we're working on that.

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

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

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

On Linux absolutely, the IO latency on MacOS with mounted volumes is atrocious. Using a nix environment also avoids the weird edge cases I tend to run into with volumes mounts and file ownership and such.

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

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

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

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

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

#46

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…

> 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) There's a dozen projects that do this. But it would honestly take you as much time to write a shell script to do it as use some other project to do it. Like, seriously: #!/usr/bin/env sh set -eu [ "${DEBUG:-0}" = "1" ] && set -x MY_TEMPLATE="${MY_TEMPL…

I understand this isn't super complex semantically, but even as someone who has used Linux full time on all of my personal desktops/laptops for 10 years now, I don't think I could write shell code like that within an order of magnitude of the time it would take me to google and find a project to do this. Maybe I'm just an outlier, but my perception is that most people don't have instant recall of advanced shell scripting features, if they're even aware of them at all. Off the top of my head:

* I think I remember that `set -e` means to exit early on error, but I don't know enough of the sharp edges to ever feel comfortable using it given how the few times I've tried I inevitably end up having it set for my entire shell session instead of only within the script and not noticed until my shell exited some time later when I made a typo * I recognize `${DEBUG:-0}` as the syntax to use the value of `$DEBUG` if it's set and `0` otherwise, but I can never remember it without googling * I'm guessing `trap _cleanup EXIT` means that `_cleanup` should be run when the script exits, but it's not clear to me whether `EXIT` is some special keyword, and if so what other values would be valid there * I don't think I've ever seen anything close to the left hand side of the `&&` in the cleanup function. Presumably it means to make sure the directory exists before trying to remove it, but I have absolutely no idea why `tmpdir` could possibly be unset or why it would even be a problem if it was even independent of the fact that I would have thought that the `-f` flag to `rm` would make it ignore the directory not existing * is the final `;` in cleanup necessary? If I got a syntax error without it, I don't think it would occur to me that it would be needed * I've never seen `??` in a path before. I'm guessing it means to try to expand `.*` but then not fail if there's nothing? I don't think I would have even thought of the edge case of the expansion not finding anything being a failure

Could I write a script that does maybe 80% of this fairly quickly? Yes. Would the remaining 20% mostly be not thinking of edge cases and then getting frustrated when using it? Probably. Would I give up at this point and just try to find some other tool to handle it for me rather than doing it myself? Almost definitely.

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

#47

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.

I would totally want to deploy on the prod environment. If the tools have their symbols resolved properly, they should run on any reasonable environment.

The other way around that we build a dev environment that is different from prod just makes no sense.

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

#48

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.

But unless you're doing all your development on cloud servers that exactly mirror the deployment architecture of your production cloud (I'm assuming we're discussing cloud application development here), then the environments are already different.

Some differences are incidental (e.g. developers using different operating systems) and Docker can help reduce those, for sure. By some differences are essential and desirable (e.g. you don't deploy your compiler).

I'm starting to think it's best to first reduce the number of differences that matter. E.g. if you're using an interpreteded language, reduce or isolate native dependencies so that most code can just depend on the right runtime version.

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

#49

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.
Post reply on HN