Drop bundled wheels for 3.7

[smoser]

What's the problem this feature will solve?

virtualenv has embedded wheels specifically to support python 3.7. python 3.7 went EOL over a year ago (i2023-06-27).

The embedded wheels

1. take up space - almost 3MB total for pip-24.0-py3-none-any.whl, setuptools-68.0.0-py3-none-any.whl and wheel-0.42.0-py3-none-any.whl.
2. contain known CVE - setuptools 68.0.0 CVE-2024-6345. That unnecessarily trips security scanners. Example here.

Describe the solution you'd like

Drop the embedded wheels.

Alternative Solutions

Maybe make it installable as a optional dependency? That would clearly take action by users of python 3.7, but they have been unsupported by upstream for over a year.

[gaborbernat]

Our policy is to support it for 18 months past python eol.

[montrellharrington-shadow]

I'm facing an issue related to the vulnerability in setuptools versions < 70.0.0, as outlined in this advisory. I've already updated the package in my pyproject.toml to setuptools = "^74.0.0", and the change is reflected in the poetry.lock file.

However, JFrog Xray still identifies the vulnerability in my application with the path /opt/poetry-venv/lib/python3.12/site-packages/virtualenv/seed/wheels/embed/setuptools-68.0.0-py3-none-any.whl.

From what I can see in the virtualenv source code, it appears that virtualenv is using version 3.7, defined by the MAX constant. My application is running on Python 3.12.6, and I’m wondering if there's a specific configuration I need to include in my Dockerfile to ensure it uses the latest setuptools .whl.

Any guidance would be greatly appreciated!

[gaborbernat]

If you are not using Python 3.7, you can ignore the warning. If you are using it, well, you are not secure anyways.

[bluss]

Fixed by #2783