Create wrappers instead of symlinks
Opened this issue · 6 comments
Many tools expect to be run from a specific location.
I've made PRs to fix this in downstream tools, but I think it's time to consider having basher write wrappers scripts that are little more than
cd $repo_path
exec ./bin/repo_nameThis would work around scripts that don't handle linking when sourcing child scripts
At least for me, i'm not convinved this should be the default since the wrapper would incur a penalty of longer execution time (largely nullifying any tool's attempts to be snappy), but maybe there could be an environment varaible / option that enables this behavior
Do you have examples that fail?
@juanibiapina asdf fails. This issue was inspired by an issue I filed with them this morning, and from the previous patches I had to submit to goenv and pyenv to get them to play nicely. Unfortunately asdf does not appear to be willing to accept such a patch, and that got me thinking about other repos that might be similarly unable to be uplifted.
@cornfeedhobo I just want to be clear, I didn't accept the patch because it was an incomplete fix (things would break) - not because I was unwilling. That's not to say this wouldn't be a useful feature - just that in the case of asdf, I don't think it applies.
By looking at install instructions for asdf, it seems to me like asdf is meant to be sourced, not used as a binary. Even if we created a wrapper here, I suspect asdf wouldn't work properly, based on the information on asdf-vm/asdf#1658
A different approach could be to add support for basher to source files from certain packages. In my experience though, finding a heuristic that works for majority of packages can be quite difficult, since there's no pattern that identifies which files should be sourced.
An alternative is to just accept asdf is an important enough project that requires and deserves its own specific installation method.
A super hopeful approach would be to create a standard for bash packages where files that need to be sourced live in a specific directory, but I have no hopes of accomplishing such a feat.
asdf is meant to be sourced
My use of exec was off-the-cuff. In reality it should probably be sourced, given the pattern.
A super hopeful approach would be to create a standard for bash packages
I can't find the origin of this pattern, but there was an original repo that started the repo convention used by many of these "bash packages", such as rbenv, pyenv, goenv, nodenv, etc. If I can track it down, I'll be sure to comment again with a link.
Edit: https://github.com/qrush/sub
asdf is an important enough project that requires and deserves its own specific installation method.
IMHO, this convention has existed for nearly 10 years now. I don't think it's special enough; and to their credit, they have outstanding issues that would address this eventually, like adding init subcommand support, but for now that doesn't seem to be a reality, and I'm just trying to make life a tiny bit easier.
I would also like to remind everyone that asdf is only one example. As I also said, I had to submit PRs to goenv and pyenv to fix the exact same issue - the main difference being that their repos were in a mature enough state that it was easy for them to accept it.
In theory, it would have been nice to not have had to submit those PRs and things still work.
Edit: Also to be clear, this proposal would still not fix asdf until they move the initialization from a script in the root, to an init subcommand.