Even with the python3.6 package installed, you can't use the 'py36' tox environment on Fedora 43. If you run tox with `-v`, you can see this error: py36: 161 I failed to query /usr/bin/python3.6 with code 1 err: ' File "/usr/lib/python3.14/site-packages/virtualenv/discovery/py_info.py", line 7\n from __future__ import annotations\n ^\nSyntaxError: future feature annotations is not defined\n' [virtualenv/discovery/cached_py_info.py:36] This was changed upstream in https://github.com/pypa/virtualenv/pull/2548 in 2023, so it may have been around for a while and I just didn't notice. I'm filing this downstream as I think it was intentional on upstream's part, they don't care to support 3.6 any more as it's long EOL upstream. Caring about it is kind of a Red Hat Extended Universe thing, because it's still the system Python in EL 8 (which is why I still kinda want to test things against it if possible, especially things there's an EPEL 8 build of).
Hello. Thank you for the report. It's unfortunate, but tox does not support EOL Pythons as long as we do. This behavior is documented with a workaround you can use, see: https://tox.wiki/en/latest/faq.html#testing-end-of-life-python-versions Unfortunately, it's currently not possible to use tox with Python 3.6 and 3.15. If you need that combo, follow this discussion: https://github.com/tox-dev/tox/issues/3656 Currently, I don't think there is anything I can do on RPM level to make this less painful.
Well, we could patch all the `from __future__ import annotations` calls to handle failure, for a start. But of course if they've started using other post-3.6 features that won't help. Will the workaround actually work? Will tox notice the packaged virtualenv is too new and get an older one from pypi or something?
(In reply to Adam Williamson from comment #2) > Will the workaround actually work? Will tox notice the packaged virtualenv > is too new and get an older one from pypi or something? Yes. It will create a "provision" venv with tox and an older virtualenv and delegate itself to it. It's rather magical, and of course, it no longer uses our RPM-packaged wheels.
(In reply to Adam Williamson from comment #2) > Well, we could patch all the `from __future__ import annotations` calls to > handle failure, for a start. But of course if they've started using other > post-3.6 features that won't help. I'm not quite sure we can pull an effort to patch virtualenv to support older Pythons. But maybe we can at least see how much effort that would be. I am afraid that eventually it will become unbearable.
OK, this is not that bad as I thought. The following two changes are the only things needed to create Python 3.6 virtualenvs (with virtualenv directly or tox) in virtualenv 20.35.4: $ sed -i '/from __future__ import annotations/d' $(grep -r 'from __future__ import annotations' venv/lib64/python3.14/site-packages/virtualenv -l) $ sed -i 's/ -> PythonInfo/ -> "PythonInfo"/' venv/lib64/python3.14/site-packages/virtualenv/discovery/py_info.py
Well, at least for now, we can do this and postpone the problem to some later date. I opened: https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/159 https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/160 Would appreciate some testing.
This works nicely on Python 3.14 where "from __future__ import annotations" is implicit. On Fedora 42, I am afraid this might be a tad more tedious :( But I'll see how much.
After further examination, we don't need to drop "from __future__ import annotations" from anything but src/virtualenv/discovery/py_info.py This makes it a much more sustainable approach than I originally expected. Too bad upstream does not want to support this :( Fedorsa 42: https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/161
FEDORA-2026-95e5c9f82c (python-virtualenv-20.35.4-3.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-95e5c9f82c
FEDORA-2026-95e5c9f82c (python-virtualenv-20.35.4-3.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-995bb86cb3 (python-virtualenv-20.29.1-6.fc42 and python-wheel0.37-0.37.1-29.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-995bb86cb3
FEDORA-2026-f4f2c6bb32 (python-virtualenv-20.35.4-3.fc43 and python-wheel0.37-0.37.1-30.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-f4f2c6bb32
FEDORA-2026-995bb86cb3 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-995bb86cb3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-995bb86cb3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-f4f2c6bb32 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-f4f2c6bb32` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-f4f2c6bb32 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-f4f2c6bb32 (python-virtualenv-20.35.4-3.fc43 and python-wheel0.37-0.37.1-30.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-995bb86cb3 (python-virtualenv-20.29.1-6.fc42 and python-wheel0.37-0.37.1-29.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.