Don't show default activated version on shell startup

[jankatins]

rtx prints the versions which get activated per default (`~/.tool-version) when I open my shell. Is there a way to prevent that and only print when I change away from it (or back to it)?

[jdx]

use RTX_QUIET=1 or rtx activate --quiet

[jdx]

I don't think it makes sense to only show this message part of the time. I get that the diagnostics aren't that helpful if you're using your home directory, but if I start displaying it sometimes and not other times it loses its debugging capability. It would also be somewhat challenging to get right.

[jankatins]

I get your point :-( Unfortunately, it's another line when starting the shell from scratch. :-(

My guess would have been something like "if _RTX_DIFF/__RTX_WATCH not set and we are using the .tool-versions from ${HOME}, don't print the versions"

[jankatins]

Made some crude approximation in the hook function by checking for "in $HOME dir" instead of "using tool versions from $HOME":

_rtx_hook() {
  trap -- '' SIGINT;
  if ! (( ${+__RTX_WATCH} )) && [[ "${HOME}" == "$(pwd)" ]] ; then
    QUIET=1
  else
    QUIET=0
  fi
  eval "$(RTX_QUIET=${QUIET} "/Users/jankatins/.local/share/zinit/plugins/jdxcode---rtx/rtx" hook-env -s zsh)";
  trap - SIGINT;
}

This is a session with no activation message at the start:

in ~
[01:55:20] λ  cd tmp # ~/tmp has a .tool-versions file
rtx: python@3.7.16 rust@1.67.0

in ~/tmp
[01:55:25] λ  cd ..
rtx: python@3.11.1 rust@1.67.0

in ~
[01:55:27] λ

[jdx]

that's fair, I'm not sure why I thought it would be challenging. Still though, hook-env is by far the most complex part of the codebase and I would very much like to reduce complexity there. I also think it would be surprising behavior for hook-env to not display diagnostics in that directory.

Perhaps at some point we can revisit this and think about pruning the output a little. Certainly for now I would prefer a slightly noisy CLI while there are still plenty of bugs to be found.

It's worth noting direnv has the same behavior except with direnv there is no way to opt out of it as I understand. There is a long thread about it here: https://github.com/direnv/direnv/issues/68. I don't have the energy now to go through a decade-old thread like that, but I would encourage you to and see if you have any thoughts on better ways to do it.

I don't like hiding this on HOME because it's not a very extensible behavior. Other people may want it to behave in other ways, maybe they want to be notified about different things like environment variable changes, or maybe they want to see a list of the legacy version files. I haven't thought this through, but perhaps a shell function callback on hook-env might be something that people could build off of. That way you could set rtx activate -q and show the diagnostics you want.

[jankatins]

I think the main issue is my usecase, as I don't use asdf/rtx as a "switch version on cd" (that's what I use direnv and venvs for) but more like a "install multiple versions of python and the current version of rust and keep them current" with the feature that it keeps old versions around so venvs don't break (that was the main issue with brew: update python, had to redo all venvs as the links were now pointing to a non-existing place). With that mindset, I think I could also get away with only running rtx env and using rtx x when I create venvs.

I'm using zinit and now this snippet to install/update and initialize rtx:

# for lbin
zinit light-mode depth"1" for \
  @zdharma-continuum/zinit-annex-binary-symlink 

zinit as'null' from"gh-r" lucid nocompile completions \
    mv"rtx* -> rtx" lbin"!rtx* -> rtx" \
    atclone'echo "eval \"\$(rtx env -s zsh)\"" > zhook.zsh && ./rtx complete --shell zsh > _rtx && mkdir -p ${HOME}/.config/direnv/lib/ && ./rtx direnv activate > ${HOME}/.config/direnv/lib/use_rtx.sh' atpull"%atclone" \
    src"zhook.zsh" \
    for @jdxcode/rtx

If I need to switch versions in some dirs, I will use direnv for that.

[jdx]

I'm not sure I understand why you can't just use rtx activate -q, if you don't use .tool-versions files, then you'd never see the diagnostic message anyways.

I suspect the reason may be that you don't want to globally set RTX_QUIET for other rtx commands, but that probably warrants some color:

1. RTX_QUIET doesn't currently do anything other than hide the diagnostic message on hook-env (at least I can't remember using it for anything else)
2. Using RTX_QUIET isn't how I want that to work long-term. The activate script should instead call rtx hook-env --quiet so that there isn't an environment variable being set that might be used for other things. It just doesn't matter today since that environment variable isn't used for anything else so there isn't a reason to make this change.
3. I probably will start using RTX_QUIET for things like hiding the spinner but I wouldn't do that until I take care of 2 here.

Or maybe I'm wrong and there is some other reason you don't want to use --quiet here.

[jankatins]

I'm not sure I understand why you can't just use rtx activate -q, if you don't use .tool-versions files, then you'd never see the diagnostic message anyways.

If I never use specific .tool-versions, then using rtx env(+ direnv) will not need any precmd commands and so save the (yeah, almost neglectable) time for this? I'm basically (mis-)using it as an multi-version package manager :-). The only thing I'll miss is, when I install a new version, the env still points to the old version. But I usually anyway have to restart my shell when I run my update-all script as it also usually updates the terminal emulator.

[jdx]

It's definitely not a mis-use, this use-case is exactly why rtx env exists. I didn't think everyone would want to use a shell extension. However rtx env doesn't show the message you opened this ticket about so I'm not sure what it is you'd like to see done.

[jankatins]

From my standpoint, this can be closed, as I switched to rtx env. Sorry that I didn't think my use case through enough before opening the ticket :-(