Open chrisjpalmer opened 7 months ago
Excited to see this pr! Why even add the option? I'd vote for just making this the unconditional behavior.
I'm down for that, just thought its better to leave the option in there in case it breaks anything for people using the tool now.
@chrisjpalmer Thanks for this very useful PR + the notes on the tests and the scenarios not handled.
Ordered install can be the default behaviour.
But I have not given any thought to how we could handle order across .tool-versions
files (especially $HOME/.tool-versions
and ${pwd}/.tool-versions
). Open to ideas.
Changed this to a draft PR since this is work in progress.
Thanks Akash. This sounds good.
I have some initial thoughts on how we can support multiple .tool-versions
files in higher directories.
First I wanted to confirm the current behvaviour.
Based on some testing and reverse engineering the code, I can see that ASDF does the following steps:
$PWD/.tool-versions
to see if there are any versions who don't have a corresponding plugin installed on the system. If there are any versions without a corresponding plugin, a message is issued and the command exits early.
.tool-versions
are not searched. .tool-versions
files for a corresponding version - starting with $PWD/.tool-versions
, going up a directory each time.Let me know if you agree with the above analysis. Assuming I'm right, then the key takeaway is that the .tool-versions
files are recursively searched and the default .tool-versions
file is considered last.
To emulate the same behaviour whilst now considering the version order in .tool-versions
I believe we need the following process:
$PWD/.tool-versions
to see if there are any versions who don't have a corresponding plugin installed... (keep this the same).tool-versions
files starting with $PWD/.tool-versions
, going up a directory each time. For each .tool-versions
file:
Just for sanity checking its important to note the following about this new process:
.tool-versions
take precedence over ones in higher directories - this is the same as the previous process which resolves the version for each plugin in earlier .tool-versions
files before searching higherLet me know what you think :) Chris
Hi there. I have actually gone ahead and implemented this. Current status is:
.tool-version
filesHey @HashNuke just checking in to see if you are happy with the progress on this PR ?
I ran the unit test suite... majority are passing!
I added a new unit test which verifies the ordered install behaviour:
install_command installs plugins in order
Note: these are failing (on my local) but I believe they are unrelated:
asdf update --head should checkout the master branch
plugin_list_all should sync repo when check_duration set to 0
I was chatting with a colleague of mine, and we were thinking that in addition to having tools be installed in .tool-version order, it might be good to consider the directory structure as well when installing tools. Suppose you have the following structure:
/
- .tool-versions: python xxx
/subdir
- .tool-versions: poetry yyy
Currently in both the previous and new install process, poetry
will be installed before python
because asdf install
installs tools in the deepest directory and the recurses upwards to shallower directories. However, there is an argument that it might be more useful to do this the opposite way. In a monorepo for example a user may specify a general tool in the root directory, and then sub directories could be free to declare additional tools. It may be possible that those additional tools have a dependency on tools declared in the root directory. Therefore it could make sense to actually modify asdf install
's behaviour to recurse from the shallower directory downwards.
Thoughts on this ?
Thanks
Hi there guys... I think this is ready for review now :)
@HashNuke or @jfly would you mind taking a look to confirm you are happy with progress ?
- Check $PWD/.tool-versions to see if there are any versions who don't have a corresponding plugin installed on the system. If there are any versions without a corresponding plugin, a message is issued and the command exits early. Note: Higher level directories with .tool-versions are not searched.
If this is the case I think this might be a bug in the old process (probably out of scope for this PR).
Recursively scan .tool-versions files starting with $PWD/.tool-versions, going up a directory each time. For each .tool-versions file:
Install versions in the order they appear in the file. Store the plugins we have installed in a variable to keep track of what we have already covered off - this allows us to skip version installs for same plugin versions as we traverse higher directories.
For the new process we might actually want to start at the uppermost .tool-versions file, installing versions in order, and work our way down to the current directory. I feel like the home/root dir is typically used for system wide stuff that the user just happens to be using asdf for (ie version doesn't vary between dirs). This is definitely a nitpick. No need to implement right now.
Currently in both the previous and new install process, poetry will be installed before python because asdf install installs tools in the deepest directory and the recurses upwards to shallower directories. However, there is an argument that it might be more useful to do this the opposite way. In a monorepo for example a user may specify a general tool in the root directory, and then sub directories could be free to declare additional tools. It may be possible that those additional tools have a dependency on tools declared in the root directory. Therefore it could make sense to actually modify asdf install's behaviour to recurse from the shallower directory downwards.
Yep, exactly!
versions without a corresponding plugin will not contribute to the installation process. This is the same as the previous process because, the previous installation process is driven by the list of plugins that do exist and hence will also ignore versions that have no corresponding plugin.
Interesting, I wonder if that is best. I don't think we should be doing anything until all required plugins (ie all those referenced in all .tool-version files at and above the current dir) are installed. Again, definitely out of scope for this PR but I think it may have ended up this way by accident rather than by design. Any idea why we might want to silently ignore missing plugins at this step?
Thanks @Stratus3D for your review. Appreciate that time you put into it. I have tried to address all your comments and respond to anything that I still wasn't sure about.
- Check $PWD/.tool-versions to see if there are any versions who don't have a corresponding plugin installed on the system. If there are any versions without a corresponding plugin, a message is issued and the command exits early. Note: Higher level directories with .tool-versions are not searched.
If this is the case I think this might be a bug in the old process (probably out of scope for this PR).
Quite possibly. We can always follow this PR up with another one which hardens this behaviour.
Recursively scan .tool-versions files starting with $PWD/.tool-versions, going up a directory each time. For each .tool-versions file: Install versions in the order they appear in the file. Store the plugins we have installed in a variable to keep track of what we have already covered off - this allows us to skip version installs for same plugin versions as we traverse higher directories.
For the new process we might actually want to start at the uppermost .tool-versions file, installing versions in order, and work our way down to the current directory. I feel like the home/root dir is typically used for system wide stuff that the user just happens to be using asdf for (ie version doesn't vary between dirs). This is definitely a nitpick. No need to implement right now.
Currently in both the previous and new install process, poetry will be installed before python because asdf install installs tools in the deepest directory and the recurses upwards to shallower directories. However, there is an argument that it might be more useful to do this the opposite way. In a monorepo for example a user may specify a general tool in the root directory, and then sub directories could be free to declare additional tools. It may be possible that those additional tools have a dependency on tools declared in the root directory. Therefore it could make sense to actually modify asdf install's behaviour to recurse from the shallower directory downwards.
Yep, exactly!
I would be happy to chase this up in a follow up PR.
versions without a corresponding plugin will not contribute to the installation process. This is the same as the previous process because, the previous installation process is driven by the list of plugins that do exist and hence will also ignore versions that have no corresponding plugin.
Interesting, I wonder if that is best. I don't think we should be doing anything until all required plugins (ie all those referenced in all .tool-version files at and above the current dir) are installed. Again, definitely out of scope for this PR but I think it may have ended up this way by accident rather than by design. Any idea why we might want to silently ignore missing plugins at this step?
Ah I think when I said that "a version without a corresponding plugin will not contribute to the installation process" what I meant was, ignoring the sanity check that runs before installation kicks off, the main installation loop ignores unknown plugins. However there is a sanity check that runs before the main installation which lets the user know if it detects an unknown plugin. This is only in place for the .tool-versions
file in the current directory. Again suggests to me a follow up PR to harden this behavior.
Thanks @chrisjpalmer! just scanned through the code and left some comments.
I see our build is broken here, but it isn't due to your changes. I'll see about fixing it on master
.
Just checking in on this as it's been a while @Stratus3D. This would be an extremely useful feature to have implemented especially for python + poetry. Seems like the remaining asks are easy cleanups that could be knocked out in 2 min
UPDATE
Summary
This PR changes the behaviour of
asdf install
to install tools in the order they are listed in.tool-versions
.The purpose is to prevent installation failures due to dependencies between plugins. An example is the
poetry
python
plugins. When runningasdf install
for these, thepoetry
plugin will typically fail because python is not available (see here). This requires the user to manually runasdf install python xxx
first and then continue with the rest of the install.Rather than maintain the correct plugin order as part of the tool, this responsibility can be forwarded to users of the tool via
.tool-versions
file.asdf install
will respect the order listed in.tool-versions
when installing the tools.Other Information
asdf update --head should checkout the master branch
plugin_list_all should sync repo when check_duration set to 0
.tool-versions
file one by one.tool-versions
fileExample
Given the following
.tool-versions
:before
after
... old PR description
Summary
This PR allows
asdf
to install tools in the order they are listed in.tool-versions
. It works by the commandasdf install --ordered-install
to be provided.The purpose is to prevent installation failures due to dependencies between plugins. An example is the
poetry
python
plugins. When runningasdf install
for these, thepoetry
plugin will typically fail because python is not available (see here). This requires the user to manually runasdf install python xxx
first and then continue with the rest of the install.The PR takes a simple approach to resolve this problem. Rather than maintain the correct plugin order as part of the tool, which is much too difficult, allow developers to maintain the order in
.tool-versions
file. Then make theasdf
tool follow that order when--ordered-install
is provided.Other Information
I have not written any tests, nor have I done extensive testing to verify this doesn't break any old functionality. I also have not addressed this change for multiple levels of
.tool-versions
files in higher directories. I can look into these things, if people like this change and we think its worth pursuing. Do let me know.Our company uses
asdf
extensively for streamlining developer workflows so we are interested in improving the tool if possible.Thanks!