6 ms·

We've been building https://devenv.sh https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved l

We've been building https://devenv.sh https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved locally.

evnix 2y ago
How is this better or different from tools like dev which use docker
- drakerossman 2y ago
  It (obviously) leverages Nix, which in turn means the environment is declarative and fully reproducible (not "reproducible" as in docker). Now, you can use just Nix's devShells, but with devenv you have a middleground between just Nix package manager and a full fledged NixOS module system. Basically, write out one line of code - and you've got your Postgres, another one - full linter set up for whatever language you're using, etc.
  - tmerse 2y ago
    Can I also get the security/isolation benefits that a duly configured docker/podman can provide (container can only act on mounted volume, non-root user, other seccomp settings?). I feel better doing my "npm install"s in such an environment (of course it's still not a VM – but that's another topic). When I read about nix, reproducibility is a goal, but security/isolation is a non-goal.
    - ParetoOptimal 2y ago
      You can generate fully reproducible OCI/docker containers with devenv, so yes I think. https://devenv.sh/containers/ https://devenv.sh/containers/
    - pxc 2y ago
      > When I read about nix, reproducibility is a goal, but [...] isolation is a non-goal. Generally, yes. But you can use or put together something like this to run Nix inside a devcontainer instead of locally: https://github.com/xtruder/nix-devcontainer https://github.com/xtruder/nix-devcontainer So you can use them in conjunction (or alternation, if for some projects you're okay running without a container) without having to specify your development environments twice. > I feel better doing my "npm install"s in such an environment (of course it's still not a VM – but that's another topic). There are basically two kinds of integration you can do for a project with Nix, which I'll call deep and shallow. In shallow integration, you just have Nix provide the toolchain and then you build the project (manually, with a script, with a Makefile, whatever). This is pretty common and pretty easy, and gives you no protection from malicious NPM build scripts. For deep integration, you can actually have Nix build your whole project. This has some downsides, like that it can't really handle incremental builds. It also imposes restrictions, like no network access by anything but Nix at build time, all packages are built by special build users with no homedirs and no perms to access anything, etc. When you do that kind of build/install, you do get some protection from crypto miners lurking in the NPM registry or PyPI or whatever.
stavros 2y ago
Nix is the right tool for this, developing a tool to make Nix's UX easier is a great idea. Thanks for this!
- dirtbag__dad 2y ago
  What about dev containers?
  - stavros 2y ago
    You mean Docker? They tend to rot much more than I'd like, mostly because you forget to pin something at some point. With Nix, you can't forget.
    - janjongboom 2y ago
      FYI, I've helped set up StableBuild (https://www.stablebuild.com https://www.stablebuild.com) to help pin stuff in Docker that's normally virtually impossible to pin (e.g. OS package repos, Docker base images, random files from the internet, etc.)
    - 1oooqooq 2y ago
      did the word rot change meaning recently? pin is what causes rot, not what solves it.
      - otabdeveloper4 2y ago
        Good luck with your Docker containers in three years. (You're gonna need it.)
      - 0x457 2y ago
        Different kind of rot. With nix and flakes, I can come back to a project 5 years later and as long as external dependencies (i.e. package sources) still available it will bring me back straight to that environment like it was yesterday. If you have a Dockerfile from 5 years ago...well good luck building it today.
pxc 2y ago
My small team uses devenv for all our development environments and we really like it. Local DX is really important to me and to our team, which is a big part of why we've chosen Nix and devenv. As we've started to use it more extensively, we've also found that we want to add some enhancements, work out some bugs, and experiment with our own customizations out-of-tree, etc. I'm happy to report here on HN that devenv is well-documented and easy to extend for Nix users who have some experience with Nix module systems, and that Domen is really responsive to PRs. :)

We've been building https://devenv.sh https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved locally.

evnix 2y ago

How is this better or different from tools like dev which use docker

drakerossman 2y ago
It (obviously) leverages Nix, which in turn means the environment is declarative and fully reproducible (not "reproducible" as in docker). Now, you can use just Nix's devShells, but with devenv you have a middleground between just Nix package manager and a full fledged NixOS module system. Basically, write out one line of code - and you've got your Postgres, another one - full linter set up for whatever language you're using, etc.
- tmerse 2y ago
  Can I also get the security/isolation benefits that a duly configured docker/podman can provide (container can only act on mounted volume, non-root user, other seccomp settings?). I feel better doing my "npm install"s in such an environment (of course it's still not a VM – but that's another topic). When I read about nix, reproducibility is a goal, but security/isolation is a non-goal.
  - ParetoOptimal 2y ago
    You can generate fully reproducible OCI/docker containers with devenv, so yes I think. https://devenv.sh/containers/ https://devenv.sh/containers/
  - pxc 2y ago
    > When I read about nix, reproducibility is a goal, but [...] isolation is a non-goal. Generally, yes. But you can use or put together something like this to run Nix inside a devcontainer instead of locally: https://github.com/xtruder/nix-devcontainer https://github.com/xtruder/nix-devcontainer So you can use them in conjunction (or alternation, if for some projects you're okay running without a container) without having to specify your development environments twice. > I feel better doing my "npm install"s in such an environment (of course it's still not a VM – but that's another topic). There are basically two kinds of integration you can do for a project with Nix, which I'll call deep and shallow. In shallow integration, you just have Nix provide the toolchain and then you build the project (manually, with a script, with a Makefile, whatever). This is pretty common and pretty easy, and gives you no protection from malicious NPM build scripts. For deep integration, you can actually have Nix build your whole project. This has some downsides, like that it can't really handle incremental builds. It also imposes restrictions, like no network access by anything but Nix at build time, all packages are built by special build users with no homedirs and no perms to access anything, etc. When you do that kind of build/install, you do get some protection from crypto miners lurking in the NPM registry or PyPI or whatever.

stavros 2y ago

Nix is the right tool for this, developing a tool to make Nix's UX easier is a great idea. Thanks for this!

dirtbag__dad 2y ago
What about dev containers?
- stavros 2y ago
  You mean Docker? They tend to rot much more than I'd like, mostly because you forget to pin something at some point. With Nix, you can't forget.
  - janjongboom 2y ago
    FYI, I've helped set up StableBuild (https://www.stablebuild.com https://www.stablebuild.com) to help pin stuff in Docker that's normally virtually impossible to pin (e.g. OS package repos, Docker base images, random files from the internet, etc.)
  - 1oooqooq 2y ago
    did the word rot change meaning recently? pin is what causes rot, not what solves it.
    - otabdeveloper4 2y ago
      Good luck with your Docker containers in three years. (You're gonna need it.)
    - 0x457 2y ago
      Different kind of rot. With nix and flakes, I can come back to a project 5 years later and as long as external dependencies (i.e. package sources) still available it will bring me back straight to that environment like it was yesterday. If you have a Dockerfile from 5 years ago...well good luck building it today.

pxc 2y ago

My small team uses devenv for all our development environments and we really like it. Local DX is really important to me and to our team, which is a big part of why we've chosen Nix and devenv. As we've started to use it more extensively, we've also found that we want to add some enhancements, work out some bugs, and experiment with our own customizations out-of-tree, etc. I'm happy to report here on HN that devenv is well-documented and easy to extend for Nix users who have some experience with Nix module systems, and that Domen is really responsive to PRs. :)