Hi all, I'm the author of <a href="https://devenv.sh" rel="nofollow">https://devenv.sh</a>, <a href="https://cachix.org" rel="nofollow">https://cachix.org</a> and <a href="https://nix.dev" rel="nofollow">https://nix.dev</a>.<p>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.<p>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.<p>I'm really looking forward what you build on top of devenv. We're only beginning to explore the area of what's possible, so please give as much feedback as you have.
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.<p>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.<p>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).<p>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.
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!<p>0 - <a href="https://news.ycombinator.com/item?id=32600821" rel="nofollow">https://news.ycombinator.com/item?id=32600821</a>
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.
There's a long tail of issues that continue to plague Nix. Sometimes, not even the fault of the Nix project itself.<p>Case in point for my current employer's Python shop - everyone runs PyCharm. Well, JetBrains doesn't really support Nix-based environments. See e.g. <a href="https://youtrack.jetbrains.com/issue/PY-42461" rel="nofollow">https://youtrack.jetbrains.com/issue/PY-42461</a> . So basically something like this would be DOA. Is this something that someone like @domenkozar can fix? @grhmc ? I don't know.
This is great! After spending some time with nix and writing <a href="https://mimoo.github.io/nixbyexample/" rel="nofollow">https://mimoo.github.io/nixbyexample/</a> I figured it’s too consuming and hard to manage nix yourself. These usable user-facing tools are really what nix needs to go to the next level
Going to ask a naive and possibly lazy question. On macOS does this replace Homebrew and MacPorts? I used to use MacPorts, now Homebrew. However, I’m thinking of switching back to MacPorts due to how painful using prior package versions is in Homebrew; sometimes I can’t run bleeding edge versions, and Homebrew’s all or nothing approach to versions isn’t working for me anymore.<p>I use Python with a few key native packages that are a pain to build myself (NumPy, GDAL primarily). Should I be considering Nix instead of MacPorts?
> Anything about Nix
> fast<p>Massive doubt.jpeg, as all my previous attempts at understanding and using Nix have all been "trust me bro, THIS random github repo source code has the Current Best Practice (already outdated)" and various other random two article blogs on how great nix is.
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.<p>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.
Another project I've been following in this space (no affiliation) is Tangram (<a href="https://www.tangram.dev/" rel="nofollow">https://www.tangram.dev/</a>), which I think of as "Nix, but TypeScript" -- or, from their Discord:<p>> Tangram takes a lot of inspiration from nix, and could be described as a mix between nix and bazel where you write JS/TS
Is there a way to specify a specific version of a language in devenv? I checked to docs and even read the nix tutorial but could not figure this out.<p>I like to idea of having this in every repository in our codebase. Would make bootstrapping easier for new developers. However, you often want a specific golang or python version. Once you update some tool or language everybody gets the new env. That would be neat. Is that possible somehow?<p>I guess initially we would roll this out just for dev and keep Dockerfiles how they are but eventually we could then use it as builder in docker.<p>Bonus question: Can I use devenv/nix together with Bazel? We use that in quite a few newer projects and it also suffers from the local dev env issue.
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.<p>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.<p>For the curious, this post[2] describes mixing Nix and Docker. And this[3] is a pretty decent tutorial on using Nix itself for this use case (consistent developer environments). Without going full NixOS, setting up a shell.nix with some OS-level environmental dependencies is a great way to dabble.<p>It seems there may be a sensible reaction away from "Dockerise all the things" for development at least, e.g. this blog post[4]. There are real downsides to containers for development, even though using things like `rvm`, `nvm` and `venv` were also a pain.<p>We've run into issues ourselves with developers starting to use the new M1 Macs - we've still not figured out how to make filesystem mounting fast yet. There seem to be other advantages to running more things locally, like simpler configuration of debuggers etc. (EDIT for clarity: the issues were with Docker, not Nix, hence the reference to filesystem mounting. Nix == "running more things locally".)<p>But taking a broader view, while containerising apps with complicated dependencies is a win, we really don't need to pretend that production and dev are actually identical environments. For example, only one of these environments needs a compiler. Once you acknowledge that the developer environment shouldn't be fully identical to prod, then you can start to think about what things <i>do</i> need to be the same, what can differ, and what your actual requirements are.<p>[1]: <a href="https://www.jetpack.io/devbox/" rel="nofollow">https://www.jetpack.io/devbox/</a><p>[2]: <a href="https://ghedam.at/15502/speedy-development-environments-with-nix-and-docker" rel="nofollow">https://ghedam.at/15502/speedy-development-environments-with...</a><p>[3]: <a href="https://nix.dev/tutorials/declarative-and-reproducible-developer-environments#declarative-reproducible-envs" rel="nofollow">https://nix.dev/tutorials/declarative-and-reproducible-devel...</a><p>[4]: <a href="https://blog.testdouble.com/posts/2020-02-11-the-slippery-slope-of-docker-dev-environments/" rel="nofollow">https://blog.testdouble.com/posts/2020-02-11-the-slippery-sl...</a>
We are using Gentoo Prefix [1] project to set up our development environment on linux. Containers etc. aren't needed as long as the elf interpreter path and rpath are set up correctly when linking the executable (or with patchelf afterwards).<p>Highly recommended.<p>[1]: <a href="https://wiki.gentoo.org/wiki/Project:Prefix" rel="nofollow">https://wiki.gentoo.org/wiki/Project:Prefix</a>
There is also devshell[1] which allows you to configure specific commands for your `env` and sits inside your flake.<p>[1]: <a href="https://github.com/numtide/devshell" rel="nofollow">https://github.com/numtide/devshell</a>
I still struggle to have the esp32 Cross Compiler Toolchain with the esp-rust llvm Compiler fork working with Nix.
Everything without the
Esp32 rust Compiler is already in nix pkg.<p>Also when trying to adopt nix for the enterprise it is still a tough barrier. At least for me struggling how to package something like the synology active backup client nix or how to setup your cups printers in nixos.<p>Besides that I hope for nix to get secure boot support.
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).<p>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".
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...
Love the experiments coming out these days: this, flox, even Replit. All working on diff approaches to a "Nix UX". Someone's going to get it right...
Will this create a container/vm for your env?<p>The current state of the software supply chain makes me very uncomfortable to install any packages.
Good luck to them, but I'll never use Nix. It's as obscure and annoying as Gentoo (or maybe more) with no practical benefits over anything else.
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.<p>Putting "developer environment" in the name of this tool perpetuates bad practices.<p>Any tool that constructs environments for applications should be general enough to handle both production and development.