Skip to content

Mark test_installation xfail on Cygwin CI #2009

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 12, 2025

Conversation

EliahKagan
Copy link
Member

@EliahKagan EliahKagan commented Mar 6, 2025

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.

Together with gitpython-developers#2007, this works around gitpython-developers#2004, allowing all tests to
pass on Cygwin CI.

In gitpython-developers#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 gitpython-developers#2004. So this just does that, for now.
@Byron
Copy link
Member

Byron commented Mar 12, 2025

Thanks a lot for your valuable support.

I don't know if this should be considered to close #2004 or not.

Generally I am leaning towards closing it to see if a user will submit a related issue.

@Byron Byron merged commit d06f8a9 into gitpython-developers:main Mar 12, 2025
24 checks passed
@EliahKagan EliahKagan deleted the cygwin-xfail-ci branch March 12, 2025 11:49
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull request Jun 14, 2025
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).
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull request Jun 14, 2025
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.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Cygwin job is broken on "Set up virtualenv" step
2 participants