- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 932
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
Cygwin job is broken on "Set up virtualenv" step #2004
Comments
It is very puzzling indeed, and seemingly impossible to error out without any form of message. |
Some of the other changes undertaken to investigate gitpython-developers#2004 may be of value, but they don't seem to be needed to get it working, so let's put them off to be evaluated later.
The absence of output is due to
I haven't found a good way to fix this entirely, but in #2007 I have worked around it by having the Cygwin CI job install |
Work around Cygwin CI failure #2004, except for `test_installation`
Instead of downloading and running the boostrap script. Various Cygwin packages have been tried here for gitpython-developers#2004, but I don't recall having explicitly specified `python39-pip-wheel`. On the Cygwin mailing list, Daniel Abrahamsson reported a problem that seems to be the same as encountered here, and noted that installing `python39-pip-wheel` fixed it. So maybe that will help here. This commit also delists the `python39-virtualenv` pacakge, which it looks like we have not been using (anytime recently) because it actually provides the `virtualenv` module and command, while we are using `venv` from the Python standard library, including on Cygwin.
Instead of downloading and running the boostrap script. Various Cygwin packages have been tried here for gitpython-developers#2004, but I don't recall having explicitly specified `python39-pip-wheel`. On the Cygwin mailing list, Daniel Abrahamsson reported a problem that seems to be the same as encountered here, and noted that installing `python39-pip-wheel` fixed it. So maybe that will help here. See: https://cygwin.com/pipermail/cygwin/2025-March/257583.html This commit also delists the `python39-virtualenv` pacakge, which it looks like we have not been using (anytime recently) because it actually provides the `virtualenv` module and command, while we are using `venv` from the Python standard library, including on Cygwin.
Instead of downloading and running the boostrap script. Various Cygwin packages have been tried here for gitpython-developers#2004, but I don't recall having explicitly specified `python39-pip-wheel`. On the Cygwin mailing list, Daniel Abrahamsson reported a problem that seems to be the same as encountered here, and noted that installing `python-pip-wheel` fixed it. So maybe that will help here. See: https://cygwin.com/pipermail/cygwin/2025-March/257583.html This commit also delists the `python39-virtualenv` pacakge, which it looks like we have not been using (anytime recently) because it actually provides the `virtualenv` module and command, while we are using `venv` from the Python standard library, including on Cygwin.
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.
The Cygwin CI test job is failing now, including when rerun at the tip of the main branch where it formerly passed. The failure occurs in the "Set up virtualenv" step, which runs
python -m venv .venv
. The log does not how a detailed error message, just:I first noticed this when checking the current status of #1988 (see #1988 (comment)), but it is not specific to that PR.
I do not know why this happens.
The text was updated successfully, but these errors were encountered: