hook-env should show unload message

[jdx]

direnv shows messages like this which I think are useful:

~ ❯ cd ..
direnv: unloading
/Users ❯ cd
direnv: loading ~/.envrc
direnv: export +RTX_DATA_DIR +RTX_LOG_FILE +RTX_LOG_FILE_LEVEL ~PATH

Currently we only show this (and nothing on unload):

rtx: shfmt@2.6.4 python@3.11.1 nodejs@18.13.0 java@openjdk-19.0.2 golang@1.19.5 ruby@3.2.0 hadolint@2.10.0 jq@1.6

We may or may not want this to be the default. For us, we would probably want to display not just the top-level config file, but all of them. That may be a lot of output. This could be a part of rtx activate --verbose or something.

If for no other reason, this would be useful for me trying to fix issues like #8

[elementalvoid]

👋 Hey @jdxcode. Firstly, I just started trying rtx out today and am intrigued. I don't think I'm ready two switch but I'm terribly interested in doing so.

More directly to this issue though: I'd love an rtx activate --verbose option as I would like to turn off the output on cd!

I manage a lot of tools with asdf in both my home dir (~/.tool-versions) and for some tools at work. So when I change dirs from one to the other it is quite verbose.

❯ cd the-tool-dir
rtx: helm@3.10.3 kubectl@1.24.9 golang@1.19.4 nodejs@19.3.0 ruby@3.1.3 stern@1.22.0 terraform@1.0.11 gradle@7.6 terraform-docs@0.16.0 python@3.11.0 bitwarden@v1.9.1 conftest@0.9.1 jq@1.6 sops@3.7.3 tfsec@1.28.1 terraform-validator@3.1.3 yq@4.30.6 sopstool@1.1.1 tflint@0.43.0 argo@3.3.10 argocd@2.5.5 java@corretto-19.0.0.36.1 helm-docs@1.11.0 tmux@3.2a awscli@2.9.10 shellcheck@0.9.0 grpcurl@1.8.7 k9s@0.26.7 tonnage@0.1.1 kind@0.17.0 chezmoi@2.28.0 rust@1.67.0 viddy@0.3.6 steampipe@0.18.1 eksctl@0.124.0 helmfile@0.149.0 kustomize@4.5.7 pluto@5.11.2 poetry@1.3.1 sinker@0.17.0 nova@3.5.0

❯ cd ~
rtx: helm@3.10.3 kubectl@1.23.15 golang@1.19.4 nodejs@19.3.0 ruby@3.1.3 stern@1.22.0 terraform@1.3.7 gradle@7.6 terraform-docs@0.16.0 python@3.11.1 bitwarden@v1.9.1 conftest@0.9.1 jq@1.6 sops@3.7.3 tfsec@1.28.1 terraform-validator@3.1.3 yq@4.30.6 sopstool@1.1.1 tflint@0.43.0 argo@3.4.4 argocd@2.5.5 java@corretto-19.0.0.36.1 helm-docs@1.11.0 tmux@3.2a awscli@2.9.8 shellcheck@0.9.0 grpcurl@1.8.7 k9s@0.26.7 tonnage@0.1.1 kind@0.17.0 chezmoi@2.28.0 rust@1.67.0 viddy@0.3.6 steampipe@0.18.1

Many are the same (i.e. inherited from home dir), some are overrides, and some are additions (by the tool).

Or, perhaps, an activate --quiet option instead? ¯\_(ツ)_/¯

[jdx]

There is already a quiet flag for this behavior

[elementalvoid]

Oops! RTFM : )

Thanks!

[jdx]

I looked into doing this today but it's actually a huge pain (I thought it'd be easy). There isn't a way to really detect when we have moved from a directory to one without anything—at least at first glance.

[kaliberr44]

What will be a huge pain? Showing loading or unloading of env variables?

Showing what vars are loaded is one thing I miss from leaving asdf and direnv to rtx.

[jdx]

specific variables is not really related. That would be easier to add. What I wanted to do in this ticket is show a message when moving away from a directory with a .tool-versions/.rtx.toml file and it doesn't seem like that is something I can easily add, I think there needs some state to be added to support it.

"huge" may be an overstatement, but in terms of value this isn't that high priority so I haven't had a chance to look into it much.

[jdx]

this is now the oldest ticket and but a related problem came up which might make this possible since the root of why both don't work is the same problem.

When I added hooks I planned to add a leave hook to show a message when leaving a project directory, however the problem is that when hook-env runs it's no longer in the directory that defined the tools so it has no way of knowing they were removed.

To support hooks, an env var__MISE_DIR is being set to track the previous directory. With that in place it would be possible to read the config files of the previous directory to check what the previous hooks/tools were in order to do this.

That said, I don't love the idea of reading in config files from a previous call. It seems bad for both performance and debugging. It would look very strange to someone trying to diagnose issues why mise would be reading config files from a directory it's not in.

Another solution I thought of that would help this case is to track the previous tools in an env var like __MISE_DIR of the previously loaded tools. That way mise wouldn't need to parse the config files. Then again, I don't love polluting the environment variables.

idk what should be done here or if the feature is even worth it

[kj]

I don't really see adding an extra environment variable as polluting the environment. That's what they're for isn't it? To describe your environment? It's definitely much better than reading the config file repeatedly. For me the feature is well worth setting one extra variable, unless I'm misunderstanding!

[jdx]

in terms of problems polluting the environment is definitely a small one that matters to few, but I don't like it when I call set and see a bunch of junk. I use that command fairly often when debugging.

My idea to solve that second problem would be to have a __MISE_SESSION variable that holds everything and it would just reference a file in ~/.local/state/mise/sessions which would contain the whole data. Then I could put whatever I want in there and nobody would see it. Not sure.