|
|
|
|
|
|
by trws
1239 days ago
|
|
|
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. |
|
|
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.