20.29.1 can't install wheels on free-threaded Python

[nedbat]

Coverage.py runs tests against the Python nightly builds. They succeed with virtualenv==20.28.1, but fail to install on free-threaded Python with virtualenv==20.29.1.

Nightly tests with 20.28.1 using commit f3f4730 succeeds.

Nightly tests with 20.29.1 using commit 0f5efe8 fails with:

  py313: install_package> python -m pip install -U --force-reinstall --no-deps .tox/.tmp/package/1/coverage-7.6.11a0.dev1-0.editable-cp313-cp313t-linux_x86_64.whl
  ERROR: coverage-7.6.11a0.dev1-0.editable-cp313-cp313t-linux_x86_64.whl is not a supported wheel on this platform.

The difference between the two commits is only the version of virtualenv: https://github.com/nedbat/coveragepy/compare/f3f4730e...0f5efe8d

I tried updating only the version of setuptools, and it succeeded.

[gaborbernat]

Cc @robsdedude

[robsdedude]

I'm making a guess here: could it be that you specify the Python version (something like the 3 in virtualenv -p python3)?

If so, there are two ways to solving this issue (apart from changing how virtualenv works, of course): either don't specify the version (e.g. virtualenv -p python) or explicitly select free-threaded Python (e.g. -p python3t).

As it stands right now, virtualenv will take any version, including free-threaded ones, when not specifying a version. If, however, a version is specified, virtualenv will respect the selection of free-threading or lack thereof.

[nedbat]

I'm using a GitHub Action matrix, which runs tox, which uses tox-gh. I can try being either less or more explicit about the version, but there are layers here that I'm not expert in. If you have suggestions, I'm open.

[nedbat]

The virtualenv is created by tox I think. I'm not sure what specifies the Python to use.

[nedbat]

I tried updating my tox.ini to have py313t and py314t:

--- a/tox.ini
+++ b/tox.ini
@@ -4,7 +4,7 @@
 [tox]
 # When changing this list, be sure to check the [gh] list below.
 # PYVERSIONS
-envlist = py3{9,10,11,12,13,14}, pypy3, doc, lint, mypy
+envlist = py3{9,10,11,12,13,14}, py3{13,14}t, pypy3, doc, lint, mypy
 skip_missing_interpreters = {env:COVERAGE_SKIP_MISSING_INTERPRETERS:True}
 toxworkdir = {env:TOXWORKDIR:.tox}

@@ -54,6 +54,12 @@ commands =
     # Test with the PyTracer
     python igor.py test_with_core pytrace {posargs}

+[testenv:py313t]
+basepython = python3.13t
+
+[testenv:py314t]
+basepython = python3.14t
+
 [testenv:anypy]
 # $set_env.py: COVERAGE_ANYPY - The custom Python for "tox -e anypy"
 # For running against my own builds of CPython, or any other specific Python.

That results in:

% tox -e py313t
py313t: pip-24.3.1-py3-none-any.whl already present in /Users/ned/Library/Application Support/virtualenv/wheel/3.13/embed/3/pip.json
py313t: install_deps> python -m pip install -U -r requirements/pip.pip -r requirements/pytest.pip
.pkg-cpython313: install_requires> python -I -m pip install setuptools
.pkg-cpython313: _optional_hooks> python /usr/local/virtualenvs/coverage/lib/python3.9/site-packages/pyproject_api/_backend.py True setuptools.build_meta
.pkg-cpython313: get_requires_for_build_editable> python /usr/local/virtualenvs/coverage/lib/python3.9/site-packages/pyproject_api/_backend.py True setuptools.build_meta
.pkg-cpython313: build_editable> python /usr/local/virtualenvs/coverage/lib/python3.9/site-packages/pyproject_api/_backend.py True setuptools.build_meta
py313t: install_package_deps> python -m pip install -U 'tomli; python_full_version <= "3.11.0a6"'
py313t: install_package> python -m pip install -U --force-reinstall --no-deps .tox/.tmp/package/1/coverage-7.6.11a0.dev1-0.editable-cp313-cp313-macosx_15_0_arm64.whl
ERROR: coverage-7.6.11a0.dev1-0.editable-cp313-cp313-macosx_15_0_arm64.whl is not a supported wheel on this platform.

py313t: exit 1 (0.23 seconds) /Users/ned/coverage/trunk> python -m pip install -U --force-reinstall --no-deps .tox/.tmp/package/1/coverage-7.6.11a0.dev1-0.editable-cp313-cp313-macosx_15_0_arm64.whl pid=51840
  py313t: FAIL code 1 (6.69 seconds)
  evaluation failed :( (6.97 seconds)

For some reason the wheel is cp313 instead of cp313t.

I feel like among virtualenv, tox, and tox-gh, I'm in a maze of twisty little repos that interact in ways I don't understand. https://github.com/tox-dev/tox/issues/3391 seems relevant too.

[robsdedude]

I didn't dig into it, so this is speculation on my part. AFAIK, tox does not recognize free-threaded Python environments. And I don't think that setting basepython to python3.13t works either. Setting it to a path might work, but I understand that that is cumbersome. So either we need to change the design of virtualenv, or make tox understand free-threaded Python specs. WDYT @gaborbernat

I designed virtualenv's understanding of free-threading in a way that users can explicitly choose a non-free-threaded build. I think that should remain an option, but maybe in a different way.

[robsdedude]

@nedbat I just had an idea. Could you try as a workaround to change your tox ini like above except with

[testenv:py313t]
basepython = python

[testenv:py314t]
basepython = python

while making sure that in CI only the free threaded versions are installed?

[nedbat]

Looks like that doesn't work: https://github.com/nedbat/coveragepy/actions/runs/12874806958/job/35894941611

[gaborbernat]

Is this still an issue?

[nedbat]

I don't have a solution yet.

[nedbat]

Anyone have any news on this? My Python nightly tests are failing with 3.13t on Ubuntu, and I'd like to debug it on my Mac but cannot.

[nedbat]

I had pinned virtualenv to avoid this issue, but now I'm running into #2878 which is breaking my nightly tests. I can't upgrade to get that fix because I'll still have this problem. Is there some way to get virtualenv working cleanly so I can keep testing nightly builds?

[robsdedude]

I think I managed to cobble together a workaround. Not the most elegant, but it seems to be working fine.

https://github.com/robsdedude/tox-gh-nogil-test

Most notable changes:

• Explicitly setting TOX_GH_MAJOR_MINOR in CI including a trailing "-t" to denote no-gil python:
  https://github.com/robsdedude/tox-gh-nogil-test/blob/e0b67b906b3b9674cf26c180a3b8a502b8b8a716/.github/workflows/test.yml#L24
• Using that info in the tox-gh config:
  https://github.com/robsdedude/tox-gh-nogil-test/blob/e0b67b906b3b9674cf26c180a3b8a502b8b8a716/tox.ini#L19
• Adding envs for no-gil Python and setting basepython in tox for those envs to pythonX.Yt to bypass tox trying to infer the right virtualenv env to create: https://github.com/robsdedude/tox-gh-nogil-test/blob/e0b67b906b3b9674cf26c180a3b8a502b8b8a716/tox.ini#L5-L8

[nedbat]

@robsdedude Thanks, your example was very helpful. I've adapted it successfully for the coverage.py actions.

[robsdedude]

I'm glad I could help. Should we close this issue? I'm not sure there's anything to be fixed with virtualenv then. This was more a question of getting tox and tox-gh to end up with the right virtualenv config.

[nedbat]

TBH, i don't know if this should be closed because I don't know what behavior is expected. @robsdedude described it as a cobbled together workaround.

[robsdedude]

@robsdedude described it as a cobbled together workaround.

I did indeed. It's a workaround for tox not understanding what free-threaded Python is. I.e., factors like py313t have no special semantics - as opposed to py313. Likewise does tox-gh, not forward weather the Python interpreter installed has a GIL or not.

The fact that it worked before was due to virtualenv (and all the other tools) being completely ignorant of free-threaded Python. So when you called virtualenv -p 3.13 you'd get a Python with or without GIL depending on which one you had installed. If you had both, I actually don't know which one you'd get. It was unspecified behaviour.

So I guess you could classify this as an incompatibility between tox and virtualenv. But I think the proper way forward is to update tox (and eventually tox-gh) to also no longer be ignorant of of free-threaded Python.

Do you have thoughts on this @gaborbernat?

[esafak]

Is this still an issue @gaborbernat , @nedbat ?

[gaborbernat]

I think should be fine, but we can reopen ifPeople still report it.