Fix "vcpkg fetch" regression where we always print that we're downloading a file even when we're not.

[BillyONeal]

#540 changed it so that we always check the versions of things, even downloaded tools. This caused a regression for all "generic" tools that we never find from the system, in that we always call "download_tool" even when we have a downloaded copy. This was detected in https://dev.azure.com/vcpkg/public/_build/results?buildId=72501&view=results where attempting to generate file lists fails because we assumed that running fetch a second time would never print status messages. ( #569 will independently fix that by printing status messages to stderr, but we should still not print misleading text )

Independently, it was bad that we never found a Python from the system, so this change makes "python3" no longer a generic tool. We should probably merge everything vcpkg_find_acquire_program does into vcpkg fetch.

• Change find_from_PATH to accept more than one stem, as happens to Python.
• Add ToolProvider::ignore_version which is used when the version of a tool can't be determined, which is true for "generic" tools.
• Adds Python3Provider.

[Neumann-A]

Independently, it was bad that we never found a Python from the system, so this change makes "python3" no longer a generic tool. We should probably merge everything vcpkg_find_acquire_program does into vcpkg fetch.

should not all tools be a vcpkg-tool-<toolname> port. Especially in the case of python where the python lib build by vcpkg and the python tool need to agree. Maybe @Hoikas can say something to that?

[BillyONeal]

Before:

After:

[BillyONeal]

should not all tools be a vcpkg-tool-<toolname> port. Especially in the case of python where the python lib build by vcpkg and the python tool need to agree. Maybe @Hoikas can say something to that?

I don't think we have consensus that we want vcpkg-tool-Xxx ports for most things, since that conveys that we want to be an acquisition channel for those tools to users, and we don't want to be.

Python in particular is the mother of all edge cases because both the Python port (which is for Python plugins, builds Python from source, etc.) and the Python artifact / fetch / etc. (which is for people who merely want a Python interpreter) are reasonable on their own and don't need to agree.

[Hoikas]

Python definitely needs to be the same across the universe, mostly due to CMake's brittle FindPython ecosystem. The current python3 port would be sufficient to provide a tool port for the host triplet.

[BillyONeal]

Python definitely needs to be the same across the universe, mostly due to CMake's brittle FindPython ecosystem. The current python3 port would be sufficient to provide a tool port for the host triplet.

We are not going to force anyone who wants a python interpreter to run meson or whatever to build python from source. Yes, this does mean that care has to be taken for things that interact with CMake's brittle handling here, but that's already the case on all *nix and MacOS systems where Python is generally available on the system in the first place.

[Hoikas]

I realize I am quickly drifting off topic, but it probably needs to be said:

We are not going to force anyone who wants a python interpreter to run meson or whatever to build python from source.

To pre-empt the next batch of issues get opened about meson ports failing on Windows 7, we should probably remove the claim of Windows 7 support, in that case. The python3 prebuilts and python3 port must stay in sync with one another, lest that brittle handling break. Unfortunately, Windows 7 Python 3 was nuked as of Python 3.8. The easiest workaround for that is to simply use our own python3[deprecatedf-win7-support]. But, since we seem to be vehemently opposed to this solution, for whatever reason, then we should probably stop pretending to support things that we don't.

[BillyONeal]

To pre-empt the next batch of issues get opened about meson ports failing on Windows 7, we should probably remove the claim of Windows 7 support, in that case.

vcpkg supports win7. That does not mean that every port and/or everything we can download on one's behalf does. We can clarify that.

The python3 prebuilts and python3 port must stay in sync with one another, lest that brittle handling break.

They are never in sync. /usr/bin/python3 is owned by apt, not us. 'fetch' is "give me the system's thing", not "give me something consistent within an installed tree" thing.