Article review: rtx + direnv + python

[Crocmagnon]

Hello there!

I wrote a draft article for my blog which I'd like to share with you in the hope that somebody could review it before I hit publish. It's fairly short (2-3 min max), I just want to avoid publishing anything obviously wrong.

Here's the link: https://gabnotes.org/setup-rtx-with-direnv-for-python/?draft_key=ac6f7ada-cec3-4aa0-90b2-21207c951a2b

I'd be thankful to get feedback from the maintainers, I intend to publish it this week if possible.

Also, the license for the post is very permissive so if by any chance you want to reuse anything, please do!

Finally: thanks for this cool piece of software! 😁

Thanks a lot 🙏🏻

[Crocmagnon]

Oh I just noticed my setup doesn't work as intended >.<

The virtualenv isn't properly activated, rtx's python version takes precedence in the PATH.

[Crocmagnon]

Ok so the setup in the article is valid then? No rtx activate and use rtx in .envrc or direnvrc?

[jdx]

yeah that should work well. I suppose if you wanted to use the experimental shims support you could get rid of the restriction that every .tool-versions has to be paired with an .envrc file, and shims in rtx are a lot faster than they are in pyenv, but I realize that's exactly what you want to avoid with rtx.

Hopefully one day I can sort this out and it'll work more seamlessly, but for now I think you probably don't want to use layout python with rtx activate.

[Crocmagnon]

Yeah, I was never a fan of shims, always found them confusing. I guess I prefer good old PATH manipulation 😁

Thanks a lot for your help! 👍🏻 😃

[jdx]

Yeah, I was never a fan of shims, always found them confusing. I guess I prefer good old PATH manipulation 😁

you and me both

[amoosbr]

For my everyday use, I also switched to direnv hook and use rtx managed PATH handling (in ~/.config/direnv/direnvrc).

The indeterministic behavior of rtx activate in combination direnv hook regarding PATH ordering was the main reason. And as mentioned in the original issue, as long as the rtx hook cannot identify which non-rtx PATH segments should stay before rtx-managed PATH segments and which after, this probably will continue to be an issue.
Calling touch .envrc && direnv allow for each .tool-versions is for me less of an inconvenience.

Switching to new rtx config format and tool plugins is not yet an option in my environment, as many colleagues are also using asdf or other tools that should continue to work.

I use the rtx shims support for the MacOS GUI apps (IDEs), but also wanted to avoid them in my shell.

Initially, I thought a global ~/.envrc file would be too slow on every terminal start (bad experience from the asdf-direnv times), but it's actually not an issue with rtx anymore.

The other inconvenience for me was, that direnv always printed the config on terminal load. As I didn't want to completely disable direnv logging on project level, I was able to work-around this by adding the following to my .zshrc file:

# set ASDF_DATA_DIR to rtx data dir to get p10k asdf option working with rtx
# https://github.com/romkatv/powerlevel10k/blob/master/internal/p10k.zsh
# also requires asdf to be on PATH. so just symlink to rtx `ln -s /opt/homebrew/bin/rtx asdf` even though symlinking asdf to rtx is not supported
export ASDF_DATA_DIR="$HOME/.local/share/rtx"

# rtx in combination with direnv calling `use rtx` in ~/.config/direnv/direnvrc
# call rtx hook-env to put JAVA_HOME, GOROOT already on environment before direnv starts
# just a convenience, to see less direnv +JAVA_HOME, +GOROOT direnv logs
eval "$(rtx hook-env)"
if [[ $PWD = $HOME ]]; then
  export DIRENV_LOG_FORMAT=
  emulate zsh -c "$(direnv export zsh)"
  unset DIRENV_LOG_FORMAT
else
  # print direnv environment, when new login shell is opened in non $HOME directory
  emulate zsh -c "$(direnv export zsh)"
fi

And to trigger a direnv reload in projects, when the global .tool-versions changed, I needed to add watch_file /Users/user/.tool-versions to ~/.config/direnv/direnvrc

With this setup, I'm, for the moment, quite happy.

[BuildBackBuehler]

Hey I like the article, I'd say if anything it could go into more detail.

As a noob, right now I'm scratching my head wondering how exactly everything plugs and plays together.

Intend to use nodejs/pnpm/python/poetry

I'm unsure if I should add or install these globally. If I do so globally, it (Poetry specifically) seems to do what you explicitly looked to avoid – being in a virtualenv everywhere.

I think it may just be a convolution but is this an issue because I used "rtx install python/poetry -g"? I'm thinking the -g causes them to be quote-en-quote "activated" and thus creating the virenv issue. Imagining "rtx install poetry" just does exactly that – install it systemically, in rtx, to be readily "activated" wherever I need it to be in a more local manner.