Alright! Another commit, another try. The format has now changed. The script section and its keys (entryscripts and exitscripts) are optional.

[env]
k = "v"

[scriptvars]
myscript = "echo 'myval'"

[scripts]
entryscripts = ["touch hello.txt"]
exitscripts = ["touch bye.txt"]

Question: Should autoenv give an error message if any section is missing (i.e env, scriptvars, scripts) or just be quiet and happy about it?

@samhedin - I'd say it should be quiet and only work with what it is given.

@samhedin - gave it a go. If I do:

> autoenv trust .

I'm able to trust the current .nu-env, and it looks like it works great without a restart.

I ran into an issue if I try to untrust in the same session:

> autoenv untrust .

If I cd into and out of the directory, I still see environment variables come and go as if the file was trusted, even though it should now be untrusted.

As I said in the original post, I didn't want to hot-reload after autoenv untrust since this would require re-reading from nu-env.toml every time you enter a command. I was afraid of how this would impact people who are running scripts inside nushell.

But things changed - now there are checks to make sure autoenv is only run once per directory change, so maybe it is fine to do IO each time. Have a look at the latest commit, changes from trust and untrust should be applied after changing dir, hopefully without slowing any scripts down!

@samhedin Cool, will keep an eye open for performance issues.

I was just trying the same test again, and getting the same result.

If you're in a trusted directory, and you untrust it, do you still see the same environment variables?

Feels like we're close.

Did it work out alright? Untrusting a directory will not immediately unset the variables - you need to leave the directory as usual. Untrust only prevents any new variables and scripts from running. Is this alright behavior?

I think the behavior of Direnv is that it actively strips any env vars that it controls when you "un-allow" a .envrc (directory)
That is the behavior I would have expected, but we should decide if that's actually the behavior we want.

Huh, interesting. I would have expected the current behavior to be the norm. I don't believe that this would be a trivial change, but if it's requested I will of course give it a proper go.

@samhedin - I think it's worth giving it a try, and seeing if it's doable.

If you run autoenv untrust in a directory, do you think that it should
a) remove all vars set by the directory and run its exitscripts
b) remove all vars set by the directory and not run its exitscripts

I'd lean towards (b). I know that could leave things in a weird state, but I think when we trust a directory, we trust it to run the scripts. When we untrust, we take back that trust and probably shouldn't run the scripts. I'd start there, at least.

I agree. I want to add that for a while I didn't even consider adding autoenv untrust. How common will it be to untrust a file you trusted previously? Not very common, I expect, since any changes would invalidate it anyway, and if you don't want it you could just delete the file itself.
Anyway, it's all ready to be tried out!

One issue remains: Vars set by ~/.nu-env are persistent across sessions(!!).

[edit]
Or they're not persistent? I am so confused it is actually insane. Are there env var caches? Vars I set long ago in the home folder stick around even if I remove them from ~/.nu-env, but new ones work as expected.

@samhedin - is it possible that it's going up into a parent directory and finding something?

This was my initial thought too, but nope. I can't reproduce the behavior anymore though...

Did some testing with the trust/untrust, scriptvars, and scripts. Things look good enough we should land this so we can use it and continue improving it based on how it feels in practice.

Thanks again for putting all this together!

@samhedin - I did notice that the paths in my nu-env.toml weren't canonical at one point but then couldn't reproduce it. Maybe you fixed something along the way?

Did some testing with the trust/untrust, scriptvars, and scripts. Things look good enough we should land this so we can use it and continue improving it based on how it feels in practice.

Super exciting! I am ready for a stream of bug reports.

@samhedin - I did notice that the paths in my nu-env.toml weren't canonical at one point but then couldn't reproduce it. Maybe you fixed something along the way?

Yes! At some point I started using std::fs::canonicalize instead of... whatever I was using before.