Welcome, and let me start by thanking you for all your work on Cachix, nix in general and your efforts to evangelize nix through things like nix.dev!
When I first picked up on devenv v0.1 I was both excited and confused. I resonate with the mission of making the definition of developer environments simple, total (no more system packages, for gods sake) and without relying on containers.
(I should note, I’m biased. I’m already a heavy user of nix and flakes. Sold on the concept, won’t stop using it until something ultimately surpasses it.)
As an outsider not involved in the devenv project I struggle to see where the distinction between nix and devenv is. It seems to want to tackle several concepts, some being “thin” nix abstractions and others breaching into the docker and docker-compose space. It makes me wonder, maaaybe I’m not the main target audience here? Or maybe I am in need of these extra “batteries”?
Some of my top level take-aways:
Deterministic (locked) inputs. This seems like nothing but a very thin wrapper around flakes or nix in general. I can see the flakes leaking through, why hide them?
Processes. Here the inspiration clearly comes from docker-compose. I’ve been missing this. Easily booting up and managing services without pulling in docker is a killer feature.
Curated development environments. Off the bat seemingly opinionated/high-level setups for language hacking. I’m all for opinionated, batteries included setups.
So, the three points above are all on kind of completely levels of abstraction and responsibility areas. I’m not yet convinced the scope of the project strikes the right balance between curation/opinions, customization and sensible abstraction over nix. But I also suspect that the vision and thought behind this project doesn’t quite manage to permeate the documentation.
I’ll jump into the Discord to hopefully learn more and stay up to date with progress!
Thanks for the throughout brain dump, that’s so much appreciated.
First off, I’d like to say that the goal of this project is to bring the benefits of Nix to people who are outside our community, by making things simple, intuitive and documented.
Comments on your takeaways:
devenv does wrap around flakes, so that you can reference and reuse flakes. But it does that by removing all the complexity of flakes. My estimate is that for a new Nix user to use flakes, they have to invest 20-40 hours to understand the language to get started.
You could say you’re not the audience to benefit from this, but if you wanted your colleagues to stop being frustrated with the complexity of Nix, this could be your shot. Once they use devenv/Nix to solve a major painpoint, they will understand and value Nix as a concept and see that what is actually hard are current unintuitive interfaces and complexities.
We recently hosted https://oceansprint.org/ and I observed well-versed Nix users don’t know from the top of their head how to do basic things via shell.nix, because there’s so much cognitive overhead. Once some time passes, I presume people will realize how much more pleasant is to remember namespaces like env. or languages., etc. Worse case you have to look up the reference.
Abstracting environments using modules allows for maximum flexibility - we’ve seen that in NixOS. There will be third-party modules that will define new options, I’m even thinking to allow setting devenv subcommands. There’s a lot to build here, but for example devcontainer.enable = true and you have codespaces support.
I hope that captures the idea that even if it’s early days, it’s worth jumping on the train even if you have no problems using the old shell interfaces.
There are a bunch of efforts in the space of “simple reproducible developer environments”, but I think devenv is the most promising one I’ve seen so far.
I created Hermit a couple of years ago, for the exact same reasons you are creating devenv. At the time I would have loved to have rolled out Nix to the 500+ engineers at CashApp, but it just would not have been a sensible choice given the complexity of Nix and how intrusive it was on OSX at the time. But given that choice today I think I would probably choose devenv. devbox is the other contender, but IMO it does too much. devenv seems to strike a better balance.
My only remaining concern is that writing Nix packages still seems prohibitively difficult for your average engineer who just wants to do their job. Hermit wins here, as the package definitions are incredibly simple, but obviously that simplicity comes with limitations.
Welcome, and let me start by thanking you for all your work on Cachix,
nixin general and your efforts to evangelizenixthrough things like nix.dev!When I first picked up on
devenv v0.1I was both excited and confused. I resonate with the mission of making the definition of developer environments simple, total (no more system packages, for gods sake) and without relying on containers.(I should note, I’m biased. I’m already a heavy user of
nixandflakes. Sold on the concept, won’t stop using it until something ultimately surpasses it.)As an outsider not involved in the
devenvproject I struggle to see where the distinction betweennixanddevenvis. It seems to want to tackle several concepts, some being “thin”nixabstractions and others breaching into thedockeranddocker-composespace. It makes me wonder, maaaybe I’m not the main target audience here? Or maybe I am in need of these extra “batteries”?Some of my top level take-aways:
flakesornixin general. I can see the flakes leaking through, why hide them?docker-compose. I’ve been missing this. Easily booting up and managing services without pulling indockeris a killer feature.So, the three points above are all on kind of completely levels of abstraction and responsibility areas. I’m not yet convinced the scope of the project strikes the right balance between curation/opinions, customization and sensible abstraction over
nix. But I also suspect that the vision and thought behind this project doesn’t quite manage to permeate the documentation.I’ll jump into the Discord to hopefully learn more and stay up to date with progress!
Hey hey!
Thanks for the throughout brain dump, that’s so much appreciated.
First off, I’d like to say that the goal of this project is to bring the benefits of Nix to people who are outside our community, by making things simple, intuitive and documented.
Comments on your takeaways:
devenv does wrap around flakes, so that you can reference and reuse flakes. But it does that by removing all the complexity of flakes. My estimate is that for a new Nix user to use flakes, they have to invest 20-40 hours to understand the language to get started.
You could say you’re not the audience to benefit from this, but if you wanted your colleagues to stop being frustrated with the complexity of Nix, this could be your shot. Once they use devenv/Nix to solve a major painpoint, they will understand and value Nix as a concept and see that what is actually hard are current unintuitive interfaces and complexities.
Fully agreed :-)
More about language roadmap at https://twitter.com/domenkozar/status/1595376770403835904
A few more points:
I’ve spent a lot of time writing the documentation and making sure very bit of devenv is documented. It goes to the extend that we have the boundary not to accept new features without documentation and have a released a tool to test snippets in markdown.
We recently hosted https://oceansprint.org/ and I observed well-versed Nix users don’t know from the top of their head how to do basic things via shell.nix, because there’s so much cognitive overhead. Once some time passes, I presume people will realize how much more pleasant is to remember namespaces like env. or languages., etc. Worse case you have to look up the reference.
Abstracting environments using modules allows for maximum flexibility - we’ve seen that in NixOS. There will be third-party modules that will define new options, I’m even thinking to allow setting devenv subcommands. There’s a lot to build here, but for example
devcontainer.enable = trueand you have codespaces support.I hope that captures the idea that even if it’s early days, it’s worth jumping on the train even if you have no problems using the old shell interfaces.
There are a bunch of efforts in the space of “simple reproducible developer environments”, but I think devenv is the most promising one I’ve seen so far.
I created Hermit a couple of years ago, for the exact same reasons you are creating devenv. At the time I would have loved to have rolled out Nix to the 500+ engineers at CashApp, but it just would not have been a sensible choice given the complexity of Nix and how intrusive it was on OSX at the time. But given that choice today I think I would probably choose devenv. devbox is the other contender, but IMO it does too much. devenv seems to strike a better balance.
My only remaining concern is that writing Nix packages still seems prohibitively difficult for your average engineer who just wants to do their job. Hermit wins here, as the package definitions are incredibly simple, but obviously that simplicity comes with limitations.
Anyway, enough rambling, best of luck :)