Would it be possible to create something similar to devbox using distrobox?

[Heus-Sueh]

devbox uses nix in the backend

distrodev is an example that uses distrobox in the backend instead of nix

When using the distrodev init command, it will create a json containing information about this distrobox

distrodev init:

{
  "distro": "arch-linux",
  "packages": {
    "python": "latest",
    "poetry": "latest",
    "cairo": {
      "version": "latest",
    },
    "gobject-introspection": {
      "version": "latest",
    }
  },
  "shell": {
    "init_hook": [
      "poetry shell"
    ],
    "scripts": {
      "run_test": "poetry run python -m poetry_demo",
      "test":     "poetry run pytest"
    }
  }
}

distrodev install will create this distrobox based on json and create a .distrodev containing the container in the directory where the user is

distrodev shell would enter the container terminal

[AngleSideAngle]

Just found this discussion - I've actually been working on something like "distrodev" this week.

The issue with using parts of distrobox-install as a backend to set up arbitrary container environments is that it works by checking what package managers are available and then making assumptions about lists of installable packages (eg. if pacman is present, distrobox-assemble assumes you're on arch and tries to install a list of arch packages). Internally, devcontainer features use a similar method to this.

The reason devbox wraps nix is because nix is a better way to install packages than containers -- instead of stuffing all the unknowns and complexity of the environment a tool needs to run into a box and ignoring it, nix knows exactly what your package depends on and can install it with its exact dependencies regardless of the state of your external system. Container images work for specifying project dev environments because, although its less elegant than nix, they can still specify a consistent environment with tools in it. There is no reason to use distrobox as a backend for defining a project's build/dev environment because all the features you want are already in container managers.

However, one of the things devbox, devcontainers, etc can't provide is user-specified (not project-specified) tools, since that requires installing arbitrary packages into an arbitrary environment. The tool I've been working on resolves this with a hack that installs arbitrary binaries (eg. nvim, zsh, git, wget, etc) in a nix image and then copies them over, along with all their dependencies (and dependencies' dependencies, etc), to a user specified image to set it up for use.

Distrobox-assemble could potentially benefit from a similar way of setting up containers (although this would be up to project maintainers), since it's more universal than the current method, although it does defeat the purpose of installing stuff from any distro, since the binaries are coming from nixpkgs.