-
-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use asdf global not working in the absence of a local .tool-versions file #35
Comments
also working on this at #37 |
Just want to let you know that I tested the pull request with the newest master of asdf and it makes it very easy to enable global tools anywhere:
I also very much like the removal of complexity, just having |
Nice, thanks for trying it out. Will be trying to shipit ASAP. |
Thanks @michi-zuri for reporting this 👍 , as i also experienced the problem as seen in #33 |
so is this problem fixed or not? i must be missing something because my entire environment doesnt work now. its not very obvious by the readme (for someone who just wants a performance improvement over asdf) that you need to have a .envrc file per each folder you decide to use.. This is not very elegent. I dont understand why this code by default just doesnt load the default asdf globals always and only when a .envrc is present changes them |
The issue that global tools do not work outside the home directory if local tools are not set is now fixed. @dagadbm if you want to use asdf with direnv outside of your /home/you (/Users/you on macOS) directory, you can leave your .tool-versions file in your home directory and just put a .envrc with the oneliner "use asdf" in your root folder: |
Let's say I have
$HOME/.tool-versions
listing my global tools:and I need to do something with my globally activated tools in
/opt/something/
Without this plugin the shims provided by
asdf
resolve the commandnpm
anddirenv
without a fuss to the one specified in above-mentioned file. With this asdf-direnv plugin, it's currently a pain to use global tools outside of the $HOME directory.For example, I could put an
.envrc
file with the following content in my root folder/
with the contentuse asdf global
, but in the absence of a/.tool-versions
file (note: also in the root folder) it will end up in an infinite loop looking for one while trying to resolve the environment.When providing an empty
/.tool-versions
file or one with just a comment it will create an environment without any tools loaded, ignoring not only the topmost/.tool-versions
but also the global tools in$HOME/.tool-versions
.When providing a
/.tool-versions
file with some content likegolang 1.13.5
it will create an environment with the global tools as specified in$HOME/.tool-versions
and ignoring the contents of/.tool-versions
as expected.Trying a different variant of the
/.envrc
file withuse asdf $HOME/.tool-versions
also results in an infinite loop, repeatedly spitting out the same error, even though the searched file exists, even if I chown and chgrp and chmod it to eliminate any possible permission problems, also happening if I write out $HOME in the envrc file as /Users/mimi:$HOME/.envrc
file withuse asdf $HOME/.tool-versions
works fine, so not sure where the problem lies. In general I failed to source a .tool-versions file that was not in the same directory as the .envrcWhat this testing revealed is that
use asdf global
does not find the global tools in the absence of a valid local project .tool-versions and that it doesn't seem possible to call.tool-versions
by path from everywhere. The latter is probably a bug.What is needed is a clean way to enable just the global tools as specified in
$HOME/.tool-versions
— without any recursive stacking or legacy file considerations — in all directories that are not a local project with their own.envrc
.I would propose that what is currently called
use asdf global
should be renamed touse asdf other
.use asdf current
would still beuse asdf other
followed byuse asdf local
, so no change is needed in the implementation of those.use asdf global
should be synonymous withuse asdf $HOME/.tool-versions
and the implementation of this should be fixed. A way should be created to load the global environment in the.bash_profile
or equivalent.The text was updated successfully, but these errors were encountered: