[bin_bash]

direnv does cause problems, but there is a workaround that functions (calling rtx within direnv). The main problem is it's annoying since you need .envrc and .tool-versions file littered through your apps (or just .envrc with "export RTX_NODEJS_VERSION=18")

There are some short term issues but I think I can resolve them in a way that direnv can't since I know exactly what PATH variables I added and didn't add. (Just remove everything with ~/.local/share/rtx prefixes.)

I could also just implement shims like asdf. The performance cost would be negligible (2-3ms of overhead for me running `rtx exec -- node -v`). I hate shims because they break `which node` though.

[trws]

The which issue is fair, but you could also consider either adding them to the shell as functions, for the wrapper effect but getting a path listing on where as part of it. Or making the rtx binary respond to argv[0] being different names such that the “wrappers” are just symlinks and save the extra exec. None of these is perfect, but they avoid the issue where path becomes too long to manage, and the function option can make them completely independent of PATH.

[jdxcode]

> adding them to the shell as functions

This, like shims, would require “reshimming” anytime a new binary is added by pip/npm. I really want to avoid that as I see juniors (and sometimes experienced devs) get in a bad state fairly often forgetting (or not understanding) reshimming.

I’m also not sure how you deal with subprocesses calling binaries. If they’re only shell functions they only exist to the shell.

> save the extra exec

rtx is already over 100x faster than asdf so this wouldn’t be necessary really. I could load test and optimize for setups with a ton of plugins and stuff if needed. My reason for avoiding shims is entirely UX related, not performance. Though I do think asdf would not have its problems if it didn’t use shims. This really is just because asdf is in bash and rtx is in rust. (I think rtx is already a lot more LOC though, and not as clean).

But in regards to PATH, I think I can get rtx to not screw up anything else that would be modifying PATH (slightly different algo than what’s currently used right now). I can’t guarantee that nothing will screw up rtx, but I can prevent direnv in particular from doing it.

It may be a game of whack-a-mole testing with different tools that modify PATH to get them to not conflict. That’s fine, it’s such a better solution.

I also think if rtx is loaded after other hooks it shouldn’t get messed with. It’s only if it gets called since potentially those tools could remove rtx paths and there isn’t much I could do about that.