Discover ASDF interpreters by default

[gauthamnair]

I struggled for a while to debug the error messages I was getting from pants (via pex), but it was ultimately because I had not added <ASDF> to the search-path.

["<PYENV>", "<PATH>"] only puts the asdf shims on the path, and they are powerless without the .tool-versions. It took me a long while to understand what was happening because even in the sandbox it looked like the asdf pythons should be findable.

In the spirit of making pants "just work" more often, and given the fair popularity of asdf, should we support asdf by default?

[gauthamnair]

Looking into why CI is failing. Its clearly due to the change, but also difficult to repro locally.

relieved, it is reproducible locally by moving my .asdf directory elsewhere. Digging in.

[gauthamnair]

this was gruesome to debug but this ends up broken if we refer to AsdfPathString.STANDARD directly. You end up with:

--python-bootstrap-search-path="[<binary-paths>, <binary-paths>, ...]"
PANTS_PYTHON_BOOTSTRAP_SEARCH_PATH
search_path
    default: [
        "<PYENV>",
        "<ASDF>",
        "<PATH>"
    ]
    current value: [
        "<PYENV>",
        "AsdfPathString.STANDARD",
        "<PATH>"
    ]

For these str-Enum compositions, the str returns the fully qualified name:

str(AsdfPathString.STANDARD) == 'AsdfPathString.STANDARD'

but the __format__() method used in f-strings returns the intended '<ASDF>'

[gauthamnair]

Current failures look to be #20103