install order should follow the order in .tool-versions

[joshlartz]

Describe the bug

Some plugins depend on others to be installed first. Despite being expressed that way in the .tool-versions file, asdf alphabetizes the install regardless.

This feels like it should be the default behavior, but at the very least there should be a flag for it.

To Reproduce

# .tool-versions
python 3.9.4
awscli 2.2.0

asdf install

Expected behavior

The .tool-versions file is installed top to bottom.

Actual behavior

The installation happens in alphabetical order.

asdf install

• Downloading awscli release 2.2.0... ~/.asdf/installs/awscli/2.2.0 ~ .asdf/plugins/awscli/bin/../lib/utils.bash: line 86: python: command not found .asdf/plugins/awscli/bin/../lib/utils.bash: line 87: ./venv/bin/activate: No such file or directory .asdf/plugins/awscli/bin/../lib/utils.bash: line 88: pip: command not found .asdf/plugins/awscli/bin/../lib/utils.bash: line 89: pip: command not found .asdf/plugins/awscli/bin/../lib/utils.bash: line 90: pip: command not found .asdf/plugins/awscli/bin/../lib/utils.bash: line 91: deactivate: command not found ~ awscli 2.2.0 installation was successful! Downloading python-build...

Environment

OS:
Darwin C02WQ018HTDD 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar  5 01:14:14 PST 2021; root:xnu-7195.101.1~3/RELEASE_X86_64 x86_64

SHELL:
zsh 5.8 (x86_64-apple-darwin20.0)

ASDF VERSION:
v0.8.0

[lifeiscontent]

@jthegedus not sure if this should be another issue, but in the regards of awscli plugin, it uses a global version of python instead of a local version, is there a way to use a locally defined tool inside a plugin?

[jthegedus]

@jthegedus not sure if this should be another issue, but in the regards of awscli plugin, it uses a global version of python instead of a local version, is there a way to use a locally defined tool inside a plugin?

Good question. It depends on the plugin implementation. Ideally, each tool installed is a standalone, pre-packaged binary. If it's not, the plugin may build the tool from source (tools with git-ref installation support likely do this).

As I understand, AWS CLI v2+ ships it's own version of python in pre-built packages. So either the plugin needs to handle installation of v2+ different to v1 and no longer rely on the system python to build (which in this case is probably in the global .tool-versions).

As for

is there a way to use a locally defined tool inside a plugin?

What version is the "local" version and who is defining it? Is this defined by the plugin, by the tool being installed or by you the installer of the tool? What is it local to?

[jthegedus]

To clarify, the reason I marked this as a bug is because elsewhere in asdf we resolve items in .tool-versions line by line, top to bottom. We should be consistent and alphabetical resolution goes against that.

The solve for this is to ensure

• [ ] asdf install resolves .tool-versions line by line

[lifeiscontent]

@jthegedus Makes sense. At the time of writing I was thinking local to the folder you execute in. E.g. I'm in project-a and I've defined a python version in .tool-versions so I'd expect that one to be used if no python executable is found. Resolution could be recursive. Shell -> Local -> Global -> System

[jthegedus]

Resolution could be recursive. Shell -> Local -> Global -> System

The resolution order is (from memory) Shell > .tool-versions in current dir and each dir up to the global .tool-versions file. system can be set in .tool-versions for a tool to fallback to the System installed version, or if no tool is found in .tool-versions, it fallsback to System.

@lifeiscontent this GitHub Discussion topic is relevant - https://github.com/asdf-vm/asdf/discussions/845

[lifeiscontent]

@jthegedus thats awesome, so if that is the case, that is not what is happening when installing awscli ~ Major version 1 which I believe is due to running some commands in a sub directory.

[lifeiscontent]

specifically due to this line: https://github.com/MetricMike/asdf-awscli/blob/2c4638b214e2081a0f3f71aa17542981f7b6b66e/lib/utils.bash#L102

[jthegedus]

@lifeiscontent you should look at this interesting plugin someone has made - https://github.com/asdf-vm/asdf/discussions/980

[tony]

@lifeiscontent you should look at this interesting plugin someone has made - https://github.com/asdf-vm/asdf/discussions/980

Any idea why this is a 404?

An area where I got snagged just now: asdf-poetry installing before asdf-python

[jthegedus]

Any idea why this is a 404?

It's a 404 because we turned off GitHub Discussions

On area where this got me: asdf-poetry installing before asdf-python

That is unfortunate. Sorry about this. I have marked this as a priority to be fixed, though, as always, PRs are welcome!

[1oglop1]

I also build a plugin for another package manager PDM https://github.com/1oglop1/asdf-pdm and the installation is the same as poetry -> pipe .py into python and the same as others the installation order breaks it.

I'm happy to contribute PR if you can give me some pointers on where to start reading the code to save me some time.

[jthegedus]

Related #1127

[dchenbecker]

Just to add another data point: the markdownlint-cli2 plugin requires a nodejs install. If you haven't installed nodejs, the command asdf install markdownlint-cli32 latest happily runs and does nothing.

[chrisjpalmer]

Made a PR here to address this. https://github.com/asdf-vm/asdf/pull/1723 If interested, let me know.