Use Existing Setup Actions When Available

[Kurt-von-Laven]

There are already a number of heavily optimized setup actions (e.g., setup-python). Python, for example, can usually be installed at a given recent version more than an order of magnitude faster using the setup-python action than via asdf (when asdf cache misses or always if you aren't using caching). It would be interesting to add a new (default) mode where the official setup actions are used in lieu of the corresponding plugin when possible, which would probably imply a major version bump. There are currently 8 GitHub-authored setup actions, which is where I would propose stopping for the first iteration of this feature. There is a long tail of setup actions authored by other organizations, so I suggest that the asdf community add support for those incrementally in a self-serve fashion if desired. It would be necessary to be able to override the proposed default behavior in case one is testing an asdf plugin itself or requires extremely high fidelity between their development environment and their CI pipeline. Please let me know if anyone has any feedback on such a feature.

[jthegedus]

I am not so much a fan of this idea. It changes the nature of using asdf completely. The idea of using the same tool and pipeline locally, across developer machines and in CI would be broken by this.

It may be quicker, but that would be because of how some of the asdf plugins work. For instance, the asdf-python plugin compiles from source. This takes a lot longer than pulling a pre-built & cached Docker image which I suspect the setup-python action does.

Having plugins which give the option to compile from source or download a pre-built binary or such would be one pathway to solve this problem.

I will be investigating caching with this action to also address some of these performance issues.

I have a lot of ideas for this action, but instead of rewriting like I was planning with all my radical ideas in one big bang, I will take small incremental steps to get there.

[Kurt-von-Laven]

The idea of using the same tool and pipeline locally, across developer machines and in CI would be broken by this.

We pin the patch version of the tools we are using, so we have encountered very little in the way of meaningful differences ourselves, but some projects will likely be more sensitive to the installation mechanism. Do you feel this concern wouldn't be addressed by offering an option to insist on a pure asdf plugin installation for those projects that require it?

Either way, I'm all for improving the performance of asdf-python; that is by far the slowest plugin we are using, and it would be nice not to require developers to install the Python build dependencies. I don't know whether it's a Docker image, but setup-python definitely installs pre-built Python from a global tool cache.

The caching technique described in #235 (comment) greatly improves performance in the cache hit case. The only performance value of the native setup actions is in the cache miss case, which we hit fairly often since we make a point of keeping up to date. Projects that upgrade less frequently likely don't mind the delay on cache miss as much. It would certainly be nice if caching didn't require the workaround described in that issue.

I'm a big fan of incremental progress in open source. Excited to see what you have in mind.

[jthegedus]

Do you feel this concern wouldn't be addressed by offering an option to insist on a pure asdf plugin installation for those projects that require it?

For this action, I think pure asdf plugin installation should be the default.

It would be good if asdf-python offered an ENV_VAR configuration option to download thse same Python builds as setup-python. Perhaps a fork or feature request to submit.

since we make a point of keeping up to date

Yeah, that would be annoying.