Implement PEP 685

[ofek]

What's the problem this feature will solve?

Ensure consistency and avoid name clashing

Describe the solution you'd like

See https://peps.python.org/pep-0685/

Alternative Solutions

N/A

Additional context

• [FR] Implement PEP 685 setuptools#3586
• Implement PEP 685 flit#535

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[burnpanck]

This is causing a lot of trouble to people not getting their dependencies resolved and not knowing why (see python-poetry/poetry#6819). PEP685 has been implemented in packaging since 9 months now (pypa/packaging#569), so it would just be an update to the vendored dependencies. Unfortunately, the corresponding feature request (#11650) has been closed as not being a bug even though it does solve a severe bug (this one), instead attention has been directed to an old, unrelated issue (#9250). However, the previous dependency update (#11502, which was 3 months after the packaging release) had missed to update packaging. In the meantime, we had a major release of pip, still not picking up this update. I'm worried that we will have to wait a full major release cycle to finally get this fixed.

[pradyunsg]

If you wish to see the upgrade happen, please feel welcome to help with #11715.

I agree that this is problematic but it's not going to magically happen because it's problematic -- this project has limited contributor bandwidth and is primarily volunteer driven. For stuff like this to happen, someone needs to step up and do things. So far, none of the typical contributors have had the time to do so.

[AndydeCleyre]

Does this issue track the following behavior, such that if this gets closed as resolved, the two numbers output will be the same?

$ pip --version
pip 24.0 from /... (python 3.12)
$ pip install --dry-run --quiet --report=- 'sentry_sdk[pure-eval]' | jq -r '.install[].metadata.name' | wc -l
3
$ pip install --dry-run --quiet --report=- 'sentry_sdk[pure_eval]' | jq -r '.install[].metadata.name' | wc -l
7

[chrysle]

Does this issue track the following behavior, such that if this gets closed as resolved, the two numbers output will be the same?

I guess so, looking at #12431.