Setuptools: 47.2.0 breaks entrypoint on installs >= 3.8

[cooperlees]

I'm only opening is cause I see the following change log notes for 47.2.0:

* 2194: Editable-installed entry points now load significantly faster on Python versions 3.8+.

With bandersnatch moving to 47.2.0 our editable install no longer runs. The exception tho seems to be from our use of importlib. So we might need to go back to using the backport it seems but wanted to get thoughts here.

...
Using legacy setup.py install for bandersnatch, since package 'wheel' is not installed.
Installing collected packages: bandersnatch
    Running setup.py install for bandersnatch: started
    Running setup.py install for bandersnatch: finished with status 'done'
Successfully installed bandersnatch-4.1.0.dev2
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.8.3/x64/bin/bandersnatch", line 9, in <module>
    for entry_point in distribution('bandersnatch==4.1.0.dev2').entry_points:
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/importlib/metadata.py", line 504, in distribution
    return Distribution.from_name(distribution_name)
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/importlib/metadata.py", line 177, in from_name
    raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: bandersnatch==4.1.0.dev2

I've opened https://github.com/pypa/bandersnatch/issues/580 to triage and root cause this. Will close if I workout it's indeed importlib.

[cooperlees]

I also plan to adding wheel as a dependency for bandersnatch so we're not lagacy. If this is going to be the new norm - Have we considered locking wheel and just making it a part of setuptools?

[ofek]

Fix https://github.com/pypa/setuptools/pull/2195

[ofek]

FWIW I can't repro locally doing the same thing as CI pip install -e ./local-package

[ofek]

Okay the CI doesn't do -e. Found the repro case:

Doing pip install ./local-package without wheel treats it as an editable install (?!) and will contain a version requirement for whatever the local version is.

[jaraco]

This sounds serious. Should we roll back and revisit?

[jaraco]

Oh, I see the PR now.

[larsoner]

FYI 47.2.0 appears to break even python setup.py install for codespell on 3.8 (vs it working on 47.1.1 before 47.2.0 was released and just now when forcing it not to use 48.2.0), so I suspect that a lot of packages will be hit by this.

[ofek]

Title should be changed as editable installs are unaffected with or without wheel.

[ofek]

Correct me if I'm wrong but I think the core issue is that local installs use the wrong generated script without wheel. Those should look like:

ofek@ozone:~$ pip3 install -q --user userpath
ofek@ozone:~$ cat $(which userpath)
#!/usr/bin/python3
# -*- coding: utf-8 -*-
import re
import sys
from userpath.cli import userpath
if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
    sys.exit(userpath())

[richardwhiuk]

I did some digging.

• distribution('bandersnatch==4.1.0.dev2') calls through to
• https://github.com/python/cpython/blob/843c27765652e2322011fb3e5d88f4837de38c06/Lib/importlib/metadata.py#L518-L524 which calls through to
• https://github.com/python/cpython/blob/843c27765652e2322011fb3e5d88f4837de38c06/Lib/importlib/_bootstrap_external.py#L1356-L1367 which calls through to
• https://github.com/python/cpython/blob/843c27765652e2322011fb3e5d88f4837de38c06/Lib/importlib/metadata.py#L478-L488 which calls through to https://github.com/python/cpython/blob/843c27765652e2322011fb3e5d88f4837de38c06/Lib/importlib/metadata.py#L490-L496

This passes Prepared as Prepared("bandersnatch==4.1.0.dev2"), which then calls through to https://github.com/python/cpython/blob/843c27765652e2322011fb3e5d88f4837de38c06/Lib/importlib/metadata.py#L455-L473

This results in versionless_egg_name being bandersnatch==4.1.0.dev2, which is wrong on the face of it.

[hidmic]

It doesn't seem like importlib.metadata.distribution supports the same distribution spec syntax that pkg_resources.get_distribution does.

[jaraco]

I believe 47.3.0 (releasing now) should fix this issue.