Dependency on direnv

[astoff]

Is the dependency on the direnv program really necessary? This dependency is not a big drawback, but I guess it is a small drawback...

Running direnv and parsing its output isn't any easier than sourcing the .envrc file in a shell and then parsing the output of env -0. And direnv's whitelisting mechanism is probably not documented, but it's not hard to reverse engineer either (alternatively, a similar mechanism to safe-local-variable-values could be used).

The more complicated part of direnv, which is to undo changes when leaving a directory, is irrelevant to this package.

[purcell]

Is the dependency on the direnv program really necessary? This dependency is not a big drawback, but I guess it is a small drawback...

Yes, it's necessary, because

Running direnv and parsing its output isn't any easier than sourcing the .envrc file in a shell and then parsing the output of env -0.

isn't really the case at all: direnv supports things like use_nix and watch_file that aren't easily replicated, and I'm not interested in doing so.

[astoff]

How is file-watching used by this package? The readme seems to imply it's not, and I would find it pretty weird if editing one file affected the state of a bunch of other buffers; this is not what happens when I save my init.el, for instance. I don't know anything about Nix, but the Python stuff provided by direnv, while possibly not easy to replicate, doesn't seem all that useful to me either.

You seem to really like those advanced features of direnv, while I prefer a minimal solution (which doesn't require more than 20 lines of shell code). That's all fine and good. But I still don't understand how this package is taking any advantage of direnv's fancy features. It's likely that other people have the same question.

For the record: This is the only among many related packages to get this per-project environment business right, therefore (1) thanks! (2) I was eager to discuss the two small points which I would have done differently.

[purcell]

Are you arguing that I don't need direnv, or that this package should support both direnv and non-direnv modes of operation?

[purcell]

Btw

How is file-watching used by this package?

File watching here is not used in the sense that you're probably thinking of it: ie. for instant reloading of a changed environment. Rather, it is part of direnv's support for caching a resulting environment based on files inside a project. So direnv file watching still makes it faster to evaluate/re-evaluate certain .envrc files from envrc.el.

[astoff]

Are you arguing that I don't need direnv, or that this package should support both direnv and non-direnv modes of operation?

The latter, or course. Actually, there are several systems for specifying a project environment besides .envrc scripts; some tools use .env (non-script) files, and for very simple Python uses it would be enough to look for a bin/activate dominating file. Maybe there's even a case for yet another package, which would be less featureful but more configurable than envrc.

Rather, it is part of direnv's support for caching a resulting environment based on files inside a project.

I would think that every .envrc script is either quick and simple or misguided, but you clearly have a counter-example. Fair enough.

[purcell]

I actually started writing a package called anyenv.el a while ago to support a variety of such use cases. Then I discovered direnv, and it basically covers them all. So I dropped anyenv.el, adopted direnv and wrote envrc.el. For that reason, I'm not keen to support anything beyond direnv in envrc.el - I'd rather the package do one thing well.

[astoff]

That's interesting, I was just sketching such a package yesterday: https://github.com/astoff/buffer-env

The idea is that you provide a file name to look up in the parent directories , ".envrc" by default, and a shell command to execute with the found file as argument and which prints the environment, ">&2 . \"$0\" && env -0" by default. I think this covers most reasonable setups, even if not optimally. Did you do something similar for anyenv?

[purcell]

anyenv at the time was something that understood how to modify the path for virtual envs, nix shells and node_modules subdirs, IIRC.

[purcell]

I'd honestly highly recommend just using direnv, since it also works in terminals and is supported in other editors, so any .envrc can be used smoothly by several team members who don't all necessarily use Emacs.

[astoff]

The above does work with direnv — as long as the .envrc script doesn't use any direnv-only extensions. One could use "direnv exec . env --null" as command for full compatibility.

[astoff]

Thanks for considering the idea.