[henryiii]

🤖 AI text below 🤖

Fixes #2984.

With the build frontend, build's isolated virtualenv seeds the pip that virtualenv bundles (26.2.2 now), not the pinned pip. pip 26.2 vendors urllib3 2.7.0, which imports ssl.VERIFY_X509_PARTIAL_CHAIN directly. GraalPy 25.0.x does not have this constant, so pip fails with TypeError: Can't create an SSLContext object without an ssl module. The GraalPy pin from #2955 only applies to cibuildwheel's own build venv, so it does not prevent this.

This PR sets VIRTUALENV_PIP to the build venv's pip version on macOS and Windows. A user-set VIRTUALENV_PIP still takes priority. Linux is not changed: manylinux installs build without the virtualenv extra, and GraalPy there uses its own patched pip.

The new test test_build_isolated_env_pip_version pins pip==25.3 and checks the pip version inside build's isolated env. I ran the same project by hand on gp312_250-macosx_arm64. It fails without the fix (('26.2.2', '25.3')) and passes with it. I could not run the CPython test locally, because there are no python.org installs on this machine.

[joerick]

Hm. Last time I checked this, VIRTUALENV_PIP had no effect on build.

I think the behaviour depends on whether virtualenv is installed. But I think build doesn't have access to virtualenv in the venvs that cibuildwheel makes.

[henryiii]

This does fix GraalPy on macOS (tested before fixing). I was fixing #2984.

🤖 AI text below 🤖

It depends on the backend that build selects. build uses the outer pip with venv only if the outer pip's RECORD lists pip/_vendor (_has_valid_outer_pip). Otherwise, if virtualenv is importable (we install build[virtualenv] on macOS and Windows), build uses virtualenv+pip, and virtualenv seeds its own bundled pip.

On macOS, we create the build venv with --symlink-app-data. With that seeder, pip's RECORD has only 7 entries and no pip/_vendor, so build falls back to virtualenv. The CI logs here show virtualenv+pip on macOS and venv+pip on Windows, where we don't use symlinks. That is why VIRTUALENV_PIP does nothing on Windows or Linux, and it explains what you saw before.

I checked locally with GraalPy 25.0.3 on macOS arm64. Without this change, the build fails with the #2984 SSLContext error. With it, the isolated env gets pip 26.1.2 and the build succeeds.

[joerick]

I checked myself locally and you're right, VIRTUALENV_PIP does take effect. Not sure what was going on last year. Maybe I made a mistake, or there was a bug.

[neutrinoceros]

Is it possible that this patch caused what looks like a regression in OpenAstronomy/github-actions-workflows#434 ?

(please be warned, I will not read or reply to AI-generated responses)

[henryiii]

No, wasn't this one, it was #3017.