Asdf: Clean up dependencies in documentation

[Stratus3D]

I think we should probably be going the other direction here. We should not be listing packages as dependencies of asdf if they are not truly packages it depends on. curl and unzip are currently not required. But neither is unixodbc I don't think. I think the asdf docs should only list actual dependencies for asdf core. For many of us it doesn't matter, but if someone is using asdf on a low power machine, or in a build, we don't want them installing unnecessary packages. For example, my Lua plugin could be used on very low power machine, and all it requires is a C compiler. Ideally all the user should be instructed to do is install asdf, asdf-lua, and the C compiler.

Plugin READMEs should already be specifying all the dependencies they require, and from what I've seen most of them are. (Please create issues on the plugin repos if you see otherwise).

_Originally posted by @Stratus3D in https://github.com/asdf-vm/asdf/pull/510#issuecomment-481933781_

[jthegedus]

I do agree we should have minimal deps listed for asdf as the core tool.

That said, I do find it difficult myself following the instructions of some plugins as most just defer to the underlying tool's documentation. It is this part of the process that I wish to improve. Ideally, each plugin would have a single code block with a copy button, as we do for the core tools.

As an example, I recently received a macOS Mojave machine for work and wanted to use the Python plugin. Not being a macOS user made this more difficult for sure, but the experience was not great. The steps I had to follow were thus:

• go to the asdf-python plugin readme
• be directed to the pyenv deps page
• install the pyenv deps
• be directed to the apple developer page for mojave dev-tool headers
• install xcode
• run some xcode select command
• go back to the asdf-python plugin readme
• be directed to python build readme
• learn that python build is a plugin for pyenv and then decide whether I install pyenv itself or python build as a standalone tool
• 🙏 I did nothing wrong

Now I understand this isn't an issue with the python plugin itself, and that this may be a worst case scenario for a new user on a new OS, but nonetheless, it's not trivial.

I would like to come up with some way to make the plugin experience as trivial as the core tool setup experience is becoming (it's not perfect yet).

Like I said in the linked PR, I have _some_ ideas.

[danhper]

I agree with both of you. In my opinion:

1. We should clean up asdf-core dependencies to keep them to a bare minimum.
2. We could improve how dependencies are handled, or at least documented

Let's keep this issue open for the first point. I just opened a new one for the second, so we can discuss ideas there #512.

[jthegedus]

On this topic and in case other find this useful, my plugins (eg asdf-gcloud) have a check_dependencies function that loops over a text file of my dependencies and runs command -v for each. On plugin add it warns of missing dependencies. On install it exits if there are missing dependencies.

• https://github.com/jthegedus/asdf-gcloud/blob/5a74763ba33731c076b615827f67a9e4ed5cf658/lib/utils.bash#L28
• https://github.com/jthegedus/asdf-gcloud/blob/master/lib/dependencies.txt

The main motivation was to stop failures on installation leaving a bad state, though I think this can be a better way for people to find the dependencies than what is usually a partial list in the README.

[jthegedus]

It seems the "plugin dependencies" section of the installation has been taking as "asdf prerequisite dependencies" and so the Homebrew installation now includes the list of deps too https://github.com/Homebrew/homebrew-core/blob/master/Formula/asdf.rb :disappointed:

Sorry for creating this mess :sweat_smile:

[Stratus3D]

I have created https://github.com/asdf-vm/asdf/pull/710 for this. I still need to implement the plugin dependency feature that I described here https://github.com/asdf-vm/asdf/issues/552.

[jthegedus]

So I believe I have determined out min required git version to be 1.7.7.2. The latest patch for that minor was 1.7.12.4 released on 2012-10-17.

This is due to the use of --work-tree I am adding in #800 which had a bug until 1.7.7.2.

We use git -C in test/test_helpers.bash in place of --git-dir and --work-tree which requires git version 1.8.5 (release notes) but it's not used in the core, just tests. 1.8.5.6 was released on 2014-12-17.

source for dates:

• https://en.wikipedia.org/wiki/Git#Releases

search for WORK_TREE in git repo RelNotes:

• https://github.com/git/git/search?p=1&q=GIT_WORK_TREE+path%3ADocumentation%2FRelNotes%2F&type=code

Now we just need to find our min curl version