We've been building https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved locally.
back
3 comments
Nix is the right tool for this, developing a tool to make Nix's UX easier is a great idea. Thanks for this!
> Nix is the right tool for this
Or Guix, which has the advantage of a more pleasant language.
At my workplace, Guix's lack of macOS support takes away some of the benefit of using something like Nix or Guix as opposed to HVM solutions like Docker Desktop or Vagrant. I imagine this situation is unfortunately common.
For teams where GNU/Linux is the primary development OS, Guix seems like a great choice.
YMMV, I really don't like lisp braces personally.
The language isn't the problem with nix.
It's not "the problem", but it's a problem. It's better than alternatives, but it's hacky nature shows.
Well, if you believe:
- discoverability is a problem in Nix
- Guix encourages or "shepherds" more discoverable functions, modules, and abstractions
Then the language could be a problem.
What is?
That's, like, just your opinion, man.
Scheme and/or Lisp is literally the worst language choice for this problem domain.
Why is Lisp the worst for this problem domain?
I will admit I find guix to be much more verbose than Nix.
For starters, a configuration language needs to be lazy by default. (Unless you want to evaluate the whole world every time you change one line.)
I wouldn't say it's the worst. I don't like Lisp and co, but I think it's alright for this. I don't like Guix for a very different reason.
What about dev containers?
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.
Err — sorry I mean https://containers.dev/
Which has pretty nice support across IDEs. For example - https://code.visualstudio.com/docs/devcontainers/containers
I set this up for my last company where we had all sorts of “works on my machine issues” and a needlessly painful onboarding experience. Local development became streamlined with this tooling BUT pre-apple silicon macs couldn’t handle running Docker like this. Glacially slow. We had a python monorepo with a bunch of services within it.
I am curious whether nix is an alternative / improvement for this. Was going down the nix road at first but an infrastructure team member steered me toward devcontainers instead and I’ve been pretty happy since!
FYI, I've helped set up StableBuild (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.)
did the word rot change meaning recently?
pin is what causes rot, not what solves it.
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.
my point stands, it's still trying to lie about the meaning of the word rot. it's just as delusional as docker original "rotting software will run in 5yrs" argument... nothing there goes against rot
Good luck with your Docker containers in three years. (You're gonna need it.)
Containers are a great deployment target, but they're not really a great development environment for a few reasons (e.g., they're Linux-specific, so they require extra virtualization on non-Linux operating systems, the kind of isolation they provide is more of a hindrance than a help when it comes to working on your local filesystem, and for them to be useful you have to set up infrastructure to push and pull your private containers to and from).
Nix is a better fit for this, and when you're using Nix you can also have Nix generated containers for deployment. I think you can also use a container with Nix in to provide the devcontainers interface to devs who don't have Nix installed locally, and have it in turn use Nix against your project's flake to set up its environment.
You can create them with devenv, but they are actually reproducible :
i missed any description of the actual container content on those examples.
IIRC, it uses what is defined for shell environment. Just instead of activating on your machine, it produces OCI image with that environment.
I have nixOS definitions that I can use to make a SD card image, overtake a running linux system via ssh, deploy to nixos via ssh, or deploy to a local system - all from one definition.
How is this better or different from tools like dev which use docker
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.
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.
> 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
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.
You can generate fully reproducible OCI/docker containers with devenv, so yes I think.
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. :)