This installs the `python-pip-wheel`, `python-setuptools-wheel`,
and `python-wheel-wheel` packages on Cygwini CI, which provide
`.whl` files for `pip`, `setuptools`, and `wheel`.
By making those wheels available, this
fixes gitpython-developers#2004 better than the
previous workaround, allowing `ensurepip` to run without the error:
Traceback (most recent call last):
File "/usr/lib/python3.9/runpy.py", line 188, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
File "/usr/lib/python3.9/runpy.py", line 147, in _get_module_details
return _get_module_details(pkg_main_name, error)
File "/usr/lib/python3.9/runpy.py", line 111, in _get_module_details
__import__(pkg_name)
File "/usr/lib/python3.9/ensurepip/__init__.py", line [30](
https://github.com/EliahKagan/GitPython/actions/runs/13454947366/job/37596811693#step:10:31), in <module>
_SETUPTOOLS_VERSION = _get_most_recent_wheel_version("setuptools")
File "/usr/lib/python3.9/ensurepip/__init__.py", line 27, in _get_most_recent_wheel_version
return str(max(_wheels[pkg], key=distutils.version.LooseVersion))
ValueError: max() arg is an empty sequence
This change takes the place of the main changes in
gitpython-developers#2007 and
gitpython-developers#2009.
In particular, it should allow `test_installation` to pass again.
This also delists non-wheel Cygwin packages such as `python39-pip`,
which are not needed (or at least no longer needed).
(The python-{pip,setuptools,wheel}-wheel packages are, as their
names suggest, intentionally not specific to Python 3.9. However,
this technique will not necessarily carry over to Python 3.12,
depending on what versions are supplied and other factors. This may
be relevant when another attempt like
gitpython-developers#1988 is made to test/support
Python 3.12 on Cygwin. At least for now, though, this seems
worthwhile for fixing the Cygwin 3.9 environment, making it more
similar to working local Cygwin environments and letting the
workflow be more usable as guidance to how to set up a local Cygwin
environment for GitPython development, and letting the installation
test pass automatically.)
Together with #2007, this works around #2004, allowing all tests to pass on Cygwin CI.
In #2007, installation of the environment in which tests run was fixed by downloading and running the get-pip.py bootstrap script. If we were to modify our helper that sets up the (separate) virtual environment in test_installation so that it does the same thing (or conditionally does so on CI, since the problem does not seem to happen in local installations), that would likely "fix" this more thoroughly, allowing the test to pass.
But part of the goal of the installation test is to test that installation works in a typical environment on the platform it runs on. So it is not obivous that making it pass in that way would be an improvement compared to marking it xfail with the exception type that occurs due to #2004. So this just does that, for now.
I don't know if this should be considered to close #2004 or not.