How you guys do ?
suppose i have a project with python, should i:
use one container and use venv to separate projects
use one container per project and dnf to install python packages instead of pip (since would be limited with the created container in toolbox)
override home from container so it would not share the host home, no needing to venv
i though on these examples, but want to hear the folks here, maybe is neither of these
I run main container for my main development and workflows and then I make another one if I need something different so my main one keeps clean and works as I want always
VScode installed as flatpak and made permissions to connect containers from podman with wrapper script
It all depends how you want to setup
My main is web development with 3D three.js and webGL
Then sometimes I do rust, python and c++/c# so then I create quick container for that one and connect on it from VScode
I have used the devcontainer project from microsoft in the past, but it was a pain to manage especially when you work in a team where every member uses a different editor.
I’m switched to the devbox project a few weeks ago. Devbox uses nix under the hood to create isolated working environments for every project.
Combined with direnv, you simply cd into your project and all your dependencies are available.
The nice thing about devbox in my opinion is that you dont need to learn nix 
On atomic desktops you need to install devbox and nix via the deterministic nix installer, the nix installer from the devbox binary doesn’t work with atomic hosts (the last time i checked it).
Another cool thing with devbox is that you can install packages globally, which makes layering of most packages obsolete.
thats cool bro, gonna take a deeper look later on this project, appears to solve some pain points.
When you have time, can you share your workflow using it , like you create a dev box per language ?
Sure, i’m currently by friends playing bordgames ^^, when i find the time i love to share my workflow, in the meantime ich can recommend the devbox docs.
also if possible when you answer, could you give a comparison with devpod and devcontainers in toolbox/distrobox ? just to understand better the benefits, i saw that the ublue variant is using devpods
Sorry for any grammatical errors, i’m not as good at english as i would like to be ^^
Devbox feels more like the “classic” dev workflow, you are more flexible in your tool choice and you have less overhead both mentally and resource wise.
But you should keep in mind that if you depend on non free software devbox doesn’t has pre build binaries for this, so it would be build on your machine.
Ive worked with devcontainers with devpod for nearly a year, in a team where everyone uses a unique distro, editor and workflow.
While devbox makes it normally more easily to setup a dev environment for a new project, because everything runs on a common base, at the same time it brings a lot of overhead and complexity to this environment.
For example networking, when you develop without all the fancy stuff you probably install all your dependencies simply with your method of choice and bind the program ports on localhost, if you use devcontainer, you need to know how to expose ports in devcontainers or when you need to install a new dependency you will need to find a devcontainer feature that installs this and rebuild the container or maintain your own custom scripts. We had the problem that some of the devcontainer features we have used where no longer maintained, so it was not possible to build our dev environments.
Then is there the editor part… vscode has a really good integration with devcontainers, but with sublime text or nvim you pretty much locked out of the workflow, sure you can install nvim in the devcontainer but you need to maintain your own install scripts for setup and it takes a bit longer to rebuild the container and you have a couple of annoying graphic bugs in nvim when it is used inside a devcontainer.
With devbox on the other hand you install your dependencies on your local machine, isolated on a directory basis. Because devbox uses nix under the hood you have access to a large number of packages and it can be used on linux, windows and macos.
Another cool thing is, that you can install packages globally. I layer only necessary system packages (docker, kvm, kitty) with rpm-ostree, all other packages (jq, nvim, fzf, starship prompt, kubectl etc.) can be installed via devbox globally. You simple need to add a line to your shell config to load the environment.
For project specific packages you run devbox init in your git repo and install packages with devbox add. With devbox shell you can load the devbox environment, if you use direnv you can generate a direnv config with devbox generate direnv and the environment gets automatically loaded if you cd into the directory. Devbox also creates a devbox.json and devbox.lock file to track the installed dependencies in git similar so other package managers.
Because devbox is simply a shell with paths to your dependencies you can start your editor of choice in this environment and all dependencies are available. And you have access to podman/docker without setting up docker in docker.
One thing if worth noticing, when you install non free software such as hashicorps vault, nix builds the package on your machine which can take a while depending on your hardware.
Devbox also caches your packages locally so when you setup a new project with the same dependencies it does not need to download or rebuild every package.
Initialize a devbox env in your git repo or project directory
devbox init
Add python and your package manager of choice
devbox add python3@3.13 poetry
load your environment
devbox shell
To automatically load the python env with the devbox shell you can add an init script to your devbox.json
devbox.json
{
"$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.12.0/.schema/devbox.schema.json",
"packages": [
"python3@3.12",
"poetry@latest"
],
"shell": {
"init_hook": "if [[ $- == *i* ]]; then poetry shell; else source $(poetry env info --path)/bin/activate; fi",
"scripts": {}
}
}
Install direnv as global package
devbox global add direnv
Load the global devbox env on shell startup
~/.zshrc
eval "$(devbox global shellenv --init-hook)"
In your project directory generate a direnv config
devbox generate direnv
Now the devbox and python env should be loaded automatically when you cd into the project directory
thanks for your detailed answer, i understand better now and will setup devbox.
may i ask with you know how/or if is possible to make devbox auto load when entering in a project from a editor like neovim ?
because with direnv and just using toolbox (my setup now), if i cd into the project directory in my terminal it auto loads direnv that trigger the venv , and if i launch neovim from there it will work with the packages.
but if im using neovim with other projects and go to a file inside a project that contains direnv it dont auto load , so the packages dont work.
afaik it is not possible to switch devbox projects inside of neovim.
i dont know your usecase for this, but when i open a file in a different project it is mostly for reference, so i like to have syntax highlighting, lsp’s etc, but i dont need the entire toolchain for the project. So i install packages that i need for the lsp, formatter, linter etc in the global scope of devbox.