General comments on v2

[rob-mur]

Hi there - thanks for the project! We are currently using v1.11.1 (stable nixpkgs) and I tried looking at v2 but had some issues. There's minor ones already open (like not being able to detach from the new process manager) but I thought I'd give you the major pain points we had which stopped the upgrade.

Apologies for the AI writing below but it helped turn the QA I had into a good summary.

Shout if you have any questions :)

Our use case and blockers for upgrading from v1 to v2

We've been using devenv as a proof-of-concept in one repo at our company. The goal is to prove it's stable and ergonomic enough to roll out further. We're a small team (<5 developers) on a shared GitLab/Kubernetes CI setup.

---

Version pinning

We're currently pinned to 1.11.1 (the version available on stable nixpkgs). This isn't a strong preference — it's a practical necessity. If developers or CI end up on different devenv versions, we run into subtle mismatches and weird behaviour. Taking stable nixpkgs is the path of least resistance; pinning individual packages in Nix is enough legwork that we've avoided it.

This means upgrading to v2 isn't as simple as bumping a version — it requires coordination across the team and CI simultaneously.

---

Blocker 1: No zsh support for the new devenv shell TUI

We have zsh users on the team. The new non-blocking shell rebuild UX in v2 is one of the more compelling reasons to upgrade, but it isn't available to zsh users, who have to fall back to direnv. This makes the upgrade harder to justify team-wide.

---

Blocker 2: CI container setup — the bashrc hack and its v2 mapping

Our CI runs on Kubernetes, which wipes the environment on every job. This makes Nix binary caching inefficient — re-downloading and recalculating deps per run is slow. Our solution is to build a CI cache image using devenv container build shell, which stays cached in the cluster.

The problem is how GitLab CI uses that image. The assumption baked into devenv container builds seems to be:

docker run <image> devenv shell -- <command>

But GitLab CI uses the image more like:

docker run --entrypoint /bin/bash <image>

In this mode, the devenv environment isn't set up — the enter shell scripting hasn't run. We also deliberately avoid calling devenv shell inside CI because it triggers a full environment rebuild, which is slow. The whole point of the image is to skip that.

Our current workaround: at container startup, we locate the bashrc that devenv generates for its direnv integration (from the Nix store) and source it directly. This is fast and mostly works — but it's fragile and undocumented, and we couldn't get an equivalent approach working reliably in v2.

It would be great if there were a supported, first-class way to activate the devenv environment in a non-interactive container context without triggering a rebuild.

---

Blocker 3: devenv container build doesn't work inside a container

We package devenv itself inside our CI image so that jobs can run devenv container build (e.g. to build and push application containers as part of the pipeline).

There are two issues here:

1. Missing directories: #2272 — /home, /etc, and similar directories aren't created in the devenv-built container, which causes devenv container build to fail when run inside it. We have a manual hack to work around this, but the fix doesn't carry over cleanly to v2. devenv uses a patched version of skopeo, and finding a compatible build between devenv's skopeo and the one we need in our image is non-trivial, so we haven't had the time to dig into it fully.

2. Version mismatch: A developer might have devenv 1.11.1 installed locally while the devenv.nix references 2.x, or vice versa. This causes confusing failures. Without an easy, low-maintenance way to pin devenv as a package, we're stuck taking whatever stable nixpkgs provides.

---

Summary

We want to upgrade and we think devenv v2 is moving in the right direction. The main things keeping us on v1 are:

• No zsh support for the new shell TUI
• No clean/supported way to activate the devenv environment inside a container without a rebuild (the bashrc sourcing approach that works in v1 doesn't map to v2)
• devenv container build failing inside a container (missing dirs + skopeo compatibility issues in v2)
• Version mismatch risk between local and CI devenv installs, with no low-friction pinning solution

Happy to provide more detail or reproduction steps on any of these.