Devbox 0.2.0: Automatic Nix installer, plugins, and background services | Hacker News Reader

Devbox 0.2.0: Automatic Nix installer, plugins, and background services

jetpack.io

60 pointstodsacerdoti32 comments

> When we run `devbox add nginx`, Devbox will use the Nginx plugin to configure our environment and create a default nginx.conf file for our project. The plugin will also add a service to our shell (see below), so we can quickly start and stop Nginx when testing our project.

This is a very cool feature, and seems like making great use of the simplified configuration DSL to me! Leveraging that simplicity to marry declarative configuration and a convenient CLI workflow seems like a smart move.

https://www.jetpack.io/devbox/ this is what this Devbox thing is

Is there any plan to add something like docker/podman's checkpoint feature that essentially lets you pause your workspace, saving it to disk similar to hibernate? I'm currently looking at using podman for dev encapsulation and this is one of the main features that attracted me.

I just tried it on WSL2 with Ubuntu to create a python-based development environment. The experience was very rough. Devbox failed on multiple levels. I had to uninstall both devbox and nix. The funny thing is that there are no uninstall instructions at all.

Is there any way to convert an existing Dockerfile to a Devbox setup in this? I usually rely a lot on other people's Dockerfiles and having a local setup ready instead would be quite handy, especially on macOS.

Hm that'd be a cool little project:

- parse out apt-get lines

- convert from apt package names to nix ones (bonus: do the same for yum or pkg)

- call devbox add with those packages

I've been looking for project idea for a while now but I might've ninja'd myself out of it now. Damn

This is a really interesting idea, and something we’ve heard from early users. I’d be interested in chatting about how something like this could be implemented

What's the difference between this and just using a default.nix/flake?

Not needing to have a PhD in Nix

I feel this. I've attempted a few times to try NixOS, and I can't seem to quite grok it for my use case. I sort of wish I could sit someone down and ask "here's what I'm doing now in rpm/deb land across all of these devices (x86, mobile, ARM). How do I do this in Nix in a sustainable way?"

Thinking about it like rpm/deb is where you're getting hung up. Think of it more along the lines of npm, but for your OS (or just your profile in the case of nixpkgs+home-manager).

At the most trivial level, you can set up some packages to install [1][2]. You'll generally come out ahead of classical package managers if you do that and nothing else.

Nix also acknowledges the configuration issue. Think of this like copying some config files using a dockerfile. You can either use literals[3], or use the nix language to generate the config [4] (provided that someone has created the required projection from nix to config).

What this ends up becoming is a single git repo with your entire system setup. My repo gets a bit fancier: I have my home desktop (currently Nixos, but it distrohops a lot), my personal laptop running Ubuntu+intune+nixpkgs for work, and then my work Mac machine (which I am aiming to get rid of). The single repo contains nix configs for all 3, and shares config where appropriate.

I really need to write a blog post about Nix in 2023. The main issue with getting started right now is that the installer requires some convincing to use flakes (not to mention that flakes are disabled by default), and you really should be using flakes.

[1]: https://gitlab.com/jcdickinson/nix/-/blob/main/system/jono-d... [2]: https://gitlab.com/jcdickinson/nix/-/blob/main/home/general.... [3]: https://gitlab.com/jcdickinson/nix/-/blob/main/home/general.... [4]: https://gitlab.com/jcdickinson/nix/-/blob/main/home/dconf.ni...

It's funny how the Devbox docs mention this explicitly:

> Don't worry: You can use Devbox without needing to learn the Nix Language.

AFAIK, a vanilla flake.nix does not help you start/stop services like docker- compose does. You need extra customization. devbox is like a wrapper around nix and docker-compose

I wonder if it would just be possible to run a nixos module instead. Like using services.nginx...

Systemd isn't exactly packaged for macOS, which I believe is one of the targets for Devbox.

Right! At some point, we could see somethinf like this in the Nix world— call it the Grand Unified Module Systwm— but right now, NixOS modules make NixOS-specific assumptions (e.g., total ownership of /etc., the use of systemd, etc.). Thus, use of such modules in other contexts (e.g., macOS in the case of Nix-Darwin, or Linux without running the whole show in the case of Home Manager) requires a distinct collection of modules.

There's been some experimental work towards this end for a long time, once under the banner of a 'service abstraction layer' for NixOS, and more recently Sander van der Burg's 'Nix Process Management Framework'. But right now, none of the mature module systems are 'universal' in the sense of being usable in all of the many environments Nix can run in.

If you were going to roll your own solution, imo using the latter of those efforts (nix-processmgmt, probably backed by supervisord) in a flake.nix or shell.nix seems like a sensible way to go. At the same time, I think using devbox to wrap all that config looks like a pretty nice way to go for teams or projects that don't already have much Nix buy-in.

I'm currently using s6 directly. It's actually pretty okay. Going to spend some more time with it as we have some more specific wants and needs than teams with less buy-in

Yeah, I think that's also a sound choice if you know you'll need more customization and you have some familiarity/preference for an existing process management tool.

Anyone know of a developer setup that uses Systemd to setup encapsulated development environments in a similar way? That sounds like it could work very nicely and wouldn't require nix.

Is this pretty similar to Toolbox? https://containertoolbx.org/

Is there a way to pin a version of the tool with this? For me, the biggest problem with Nix is that version pinning is not easy, actually it is complex.

Pinning is first-class with the new flake method. When you create a flake, a corresponding flake.lock is created, similar to lock files in other languages. There's even a dedicated command now to upgrade the dependencies declared in a flake.

Yes, I think I get that. But it is not easy to pin on different packages. For example if I want golang 1.18, node 12, I need to find the commit corresponding to those and add them. I mean it is possible but not as easy as it should be.

There's often a bunch of different versions in nixpkgs. For example, postgres currently has 11 through 15 available (https://github.com/NixOS/nixpkgs/blob/e7f345ca81f4f5513c4e73...). Nodejs has 14, 16, 18, and 19 (https://github.com/NixOS/nixpkgs/blob/e7f345ca81f4f5513c4e73...).

Finding a way to install a specific version - not git commit or git tag, version - of a package is the problem.

https://github.com/NixOS/nixpkgs/issues/93327

Nix before flakes used channels, each with a flat global namespace. Flakes are intended to sit inside the git repo, so that's even less discoverable.

Nix solves practically every technical problem, but has terrible UX and documentation.

Hello! When you add packages with Devbox add, we automatically pin your devbox.json to a specific commit in the Nix store. This ensures that any developer who uses your devbox.json will get the same packages that you do.

You can read more about how it works here:

https://www.jetpack.io/devbox/docs/guides/pinning_packages/

I guess that only pins tools by nixpkgs version, or does it have capability to pin by exact version of tools like say go 1.18, pg 12, node 16 etc?

No, because older software versions are dropped often rather quickly, especially if they are not maintained by upstream anymore, to reduce required maintaince work on them.

this looks interesting but how is this better than just doing docker-compose?

Software runs at native speed on your native filesystem. This is especially notable on macOS, where accessing any "mounted" file inside a Docker container uses a network filesystem. The docker filesystem situation can make software like Webpack or other compilers 100x slower when running inside a container on a macOS host. You also avoid UID/GID mapping between host and guest, weird permissions issues like compiler output owned by root, awkward port forwarding, and other little papercuts.

Thanks, I didn't realize nix worked well on macOS..

That sounds like a nice solution when developing on macOS. Is there any benefit then on linux?

I prefer to dev in a linux VM for security sake anyways.

Reply on news.ycombinator.com