1. 35
    1. 11

      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:

      1. 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?
      2. 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.
      3. 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!

      1. 7

        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:

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

        2. Fully agreed :-)

        3. More about language roadmap at https://twitter.com/domenkozar/status/1595376770403835904

        A few more points:

        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.

        1. 4

          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 :)