fix: include host Python version in header

[henryiii]

Adds the host Python version to the printout, would be useful for cases like #542 where you can't tell which Python this is running on, and might help us see if #508 is a good idea yet.

I've removed the word "version" from the cibuildwheel part to make it line up a bit better under the ASCII art. (Didn't realize it would line up that well. :) )

     _ _       _ _   _       _           _
 ___|_| |_ _ _|_| |_| |_ _ _| |_ ___ ___| |
|  _| | . | | | | | . | | | |   | -_| -_| |
|___|_|___|___|_|_|___|_____|_|_|___|___|_|
 
cibuildwheel 1.7.4 - hosted on Python 3.9.1

[joerick]

Hm. I guess? I'm not sure why a user would need to know, though, it's actually irrelevant because all their code will be run in other Pythons. If I'm being really critical, it might do more harm than good, since the Pythons-running-Pythons thing is inherently confusing, adding another version number in the logs has the potential to be misread or misunderstood...

Minor thing, but I'm slightly opposed, tbh. Maybe it could be hidden behind some kind of debug flag?

[henryiii]

That's why I added "hosted on"; I think it might help a bit with transparency. Especially with our planned diagram, it might make it clearer what's going on. It also means I can dig through other project's CI logs and see what the common runner Python versions are. :)

I could hide it via a flag or envvar, and then turn it on by default for the Action, though, if that's better?

[joerick]

Could https://pypistats.org/packages/cibuildwheel be any use for you? You can also use BigQuery to select the latest release- that looks like:

SELECT t0.num_downloads, t0.python_version FROM (SELECT
  COUNT(*) AS num_downloads,
  REGEXP_EXTRACT(details.python, r"^(\d+\.\d+)") as python_version,
FROM `the-psf.pypi.downloads*`
WHERE
  _TABLE_SUFFIX
    BETWEEN FORMAT_DATE(
      '%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))
    AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
    AND file.project LIKE 'cibuildwheel'
    AND file.version LIKE '1.7.4'
GROUP BY python_version
ORDER BY num_downloads DESC) AS t0 LIMIT 100;

Row	num_downloads	python_version
1	5697	3.9
2	1320	3.7
3	1141	3.8
4	331	null
5	261	3.6

[henryiii]

The question I'm trying to answer is "what version of Python does the built-in pipx on the ubuntu-18.04 use? I'm 90% sure it's Python 3.6.9, which would mean we should postpone #508 until ubuntu-18.04 is not common anymore (it's still even ubuntu-latest. (Which is fine, it's nice but not something we have to have - 3.6 is still loads better than 2.7 or even 3.5!). If there's an easy way to specify the cached Pythons, there are plenty of them, but I'm not sure if GitHub provides a way to access those (and Azure). Without a host printout, there's no way to detect in the logs what uses: joerick/cibuildwheel@... runs on.

The large number of 3.9's is from setup-python or other CI equivalent with no version set, I bet. :)

[henryiii]

Plus, if it breaks for someone and they send us the logs, knowing the host Python version might help us debug? (though, honestly, MyPy really helps here - it's great at verifying that you really support the version you say you support)

[joerick]

I added a job to this PR to investigate what pipx does - looks like it uses the Python3.6 supplied in the image:

Run pipx run pytest `mktemp -d`
============================= test session starts ==============================
platform linux -- Python 3.6.9, pytest-6.2.1, py-1.10.0, pluggy-0.13.1
...

[henryiii]

Okay, great, that's what I feared. We should hang on to 3.6 for now until either no one cares about ubuntu 18.04, or we find something we can add to pipx --python <?> ... to select one of the cached Pythons, at least on 18.04.

I can make a little throw away repo to test this, so will close this PR. Might bug GitHub, they are adding python3 to Windows for me. :) Thanks!