asdf icon indicating copy to clipboard operation
asdf copied to clipboard

command line should suggest how to default back to system version

Open eoghanmurray opened this issue 3 years ago • 3 comments

Problem scenario

I'm not invested in asdf, but it was a requirement of another project I cloned. Don't get me wrong, I think it's a great project, however I'm experiencing the following issue.

The recommended install process must have altered my bash scripts (without me thinking too much of it):

$ grep -d skip asdf ~/.*
~/.bashrc:. $HOME/.asdf/asdf.sh
~/.bashrc:. $HOME/.asdf/completions/asdf.bash

Now in an unrelated project, asdf has "taken over" and "hijacked" my normal build process.

~/other-project$ yarn install
No version is set for command node
Consider adding one of the following versions in your config file at 
nodejs 16.14.0
nodejs 16.13.1

This of course worked before I installed asdf — other-project does not require or is not aware of asdf

The above error message also does not mention asdf! It took me a while to link the error back to the recent install of the asdf-requiring codebase.

Describe the proposed solution

From reading asdf documentation, I see that the following might work:

asdf global nodejs system

Could that be given as an extra recommendation for the above error message:

~/other-project$ yarn install
No version is set for command node
Consider adding one of the following versions in your config file at 
nodejs 16.14.0
nodejs 16.13.1
If this project does not have a .tool-versions file or does not use asdf, you can revert to the system version of nodejs with

   asdf local nodejs system (for just this folder)

or

   asdf global nodejs system

(someone may need to enlighten me as to whether asdf global nodejs system takes precedence over versions set in .tool-versions)

Describe similar asdf features and why they are not sufficient

?

Describe other workarounds you've considered

Other workarounds: disabling asdf by uninstalling the first project and recommending they don't mess with my system

eoghanmurray avatar Sep 16 '22 08:09 eoghanmurray

2022? I'm also interested in this use-case for the same reasons. I added asdf for a single project for another company, but it's messing with the scripts from other projects.

Maybe we need a way for it to only assert itself when there's actually a tools version file in the file hierarchy.

Since I use oh-my-zsh and the plugin that runs .env files when I enter a directory, I'm currently using that to trigger asdf only when I enter the directory for that project.

ironspecs avatar Nov 30 '23 08:11 ironspecs

I wrote a better version. If you add this into your .zshrc, it'll check for the existence of the tool versions file, and if it exists, only then will it initialize asdf.

# Function to check for .tool-versions and initialize asdf
initialize_asdf_if_needed() {
  if [[ -f ".tool-versions" ]]; then
    echo "Initializing asdf for this project..."
    source $(brew --prefix asdf)/libexec/asdf.sh
  fi
}

# Add the function to the chpwd hook
autoload -U add-zsh-hook
add-zsh-hook chpwd initialize_asdf_if_needed

# Run the function for the initial directory
initialize_asdf_if_needed

ironspecs avatar Nov 30 '23 09:11 ironspecs

If you add this into your .zshrc

The workaround for me was trivial when I discovered the problem (uninstall asdf). I could have invested more time if I needed to get different projects working better together, and your .zshrc solution would be one such solution.

But I made this bug report to say that asdf causes unexpected behaviour outside of a target project, and it could do better in terms of self documenting it's presence.

eoghanmurray avatar Dec 04 '23 10:12 eoghanmurray