devenv conventions and DIRENV_ALLOW

[devinrsmith]

I'm trying to make sure I understand devenv conventions and how it works with DIRENV_ALLOW, https://github.com/systemstart/claude-microvm#nix-dev-shell-support

Looking at

claude-microvm/flake.nix

Lines 255 to 256 in 676d2fc

	if [ "''${DIRENV_ALLOW:-0}" = "1" ] && { [ -f "$WORK/flake.nix" ] || [ -f "$WORK/.devenv.flake.nix" ]; }; then
	_CURRENT_HASH="$( (cat "$WORK/flake.nix" "$WORK/flake.lock" "$WORK/.devenv.flake.nix" "$WORK/devenv.nix" "$WORK/devenv.yaml" "$WORK/devenv.lock" 2>/dev/null || true) | sha256sum | cut -c1-16)"

, I see that the top level must contain flake.nix or .devenv.flake.nix file.

I'm trying to follow devenv "best practices", and they suggest starting with devenv CLI:

https://devenv.sh/guides/using-with-flakes/#choosing-between-devenv-and-nix-flakes
https://devenv.sh/getting-started/#initial-set-up

$ devenv init
• Creating devenv.nix
• Creating devenv.yaml
• Creating .gitignore

I'm doing this for an existing project that hasn't used nix before. Neither flake.nix, nor .devenv.flake.nix is being created. Doing a bit of looking, it seems like .devenv.flake.nix was an internal implementation detail on previous versions of devenv, maybe no longer relevant?

[systemstart]

You're right on both counts — thanks for reporting it. The second point is the
more interesting one.

devenv init writes devenv.nix, devenv.yaml and .gitignore, and the gate
required flake.nix or .devenv.flake.nix, so a project created exactly as
devenv's guide describes matched neither. The block was skipped whole, which is
why you got no error: the only code that reports anything lives inside the block
that never ran, so DIRENV_ALLOW=1 quietly did nothing at all.

And .devenv.flake.nix was the wrong thing to look for even back when it was
written to the project root. devenv's own generated .gitignore starts with
.devenv* — it's build state, not project source, and it doesn't exist until
something has already built the shell. Keying detection on it effectively asked
"has this project been built before?" when the question is "is this a devenv
project?". devenv.nix is the file devenv init writes and the one that gets
committed, so that's the marker now.

Fixed on main:

• devenv.nix joins the gate, so a stock devenv init project is recognised.
• The command is chosen by whether a flake.nix exists rather than by which
  devenv artifact does. No flake at the top level means only devenv can
  evaluate the project, whatever else is present. flake.nix + devenv.nix
  still goes through nix print-dev-env --impure, and a plain flake is
  unchanged.
• .devenv.flake.nix stays as a fallback so older layouts keep working, but
  nothing depends on it any more.

Both silent paths now say something on the console: DIRENV_ALLOW=1 against a
directory with neither marker warns that there's no dev shell to load, and a
devenv project on a host without devenv on PATH warns up front instead of
leaving the reason in ~/.microvm-devshell.err for you to find afterwards.

Verified against devenv 2.2.2 across the combinations: devenv-only, flake-only,
flake.nix + devenv.nix, the legacy .devenv.flake.nix, neither, and
devenv-not-on-PATH.

One thing worth flagging while you're here, since it applies to devenv projects
exactly as it does to flakes: DIRENV_ALLOW=1 evaluates the project's Nix code
on the host, before the VM boots. That's deliberate — it's what keeps Nix
evaluation out of the guest — but it does mean a devenv.nix the agent can edit
gets evaluated on the host on the next launch. It's covered in the README under
Hardening notes; worth knowing before pointing it at something you wouldn't run
outside the VM.