Stop recognizing files ending with .dist-info as dist

[McSinyx]

Summary of changes

As proposed in PEP 376, dist-info distributions must be directories.

Closes pypa/pip#8122.

Pull Request Checklist

• Changes have tests
• News fragment added in changelog.d

Edit: apparently files with dist-info extension seems to be an supported behavior for setuptools. I'll try to investigate why.

[McSinyx]

tox cannot build setuptools locally for me either, even on master 😞 I'm not sure what to do please help! Seemingly we have some dependencies undeclared.

[jaraco]

I'm uneasy just dropping support for this usage. Presumably someone created it with a purpose. Even the pep makes a nod to backward compatibility, basically not addressing the issue and hoping to create a new tool that's not limited by the behavior.

If Setuptools is to drop support for these files, we should know why those were created and how a user whose environment has those files needs to react.

[jaraco]

tox cannot build setuptools locally for me either, even on master

It's building for me locally and on CI, so probably the issue is in your environment or due to your patch. It may be that when you switched to master, you still had a corrupted environment, so you may want to tox -r or git clean -fdx (destructive of ignored files).

[McSinyx]

Could you please give me some me some context about the mentioned backward compatibility? I am too young to be familiar with none of the name listed in that section in the PEP.

we should know why [files ending with .dist-info] were created and how a user whose environment has those files needs to react.

This is to solve the linked pip issue, which IIRC occurs when Docker replace the original directory with a white-out file with the same name extension. I am unaware (again, my experience is very limited) of any actual use of dist-info as a file, since

• dist-info AFAIK is an invention by PEP 376, which specifies that it is a directory
• The issue popped up on pip for the first time, and I imagine that if there is there's some project already creating it as a file, statistically there should be more instances of the crash

Since this was to fix pip's problem, I'd be happy to simply do some try-except over there instead. While the current behavior of pkg_resources is not 100% PEP-376-compliance, I don't want any of us to be responsible of breaking someone else's setup. That being said, I'd be grateful if you can take another look at it though.

Thanks for the tips about the tests BTW, I'm feeling so dumb now 😄 should have figured that out earlier. Edit: converted to draft because I have yet to be able to debug this.

[jaraco]

If the only reason these dist-info files exists is because of Dockerfile whiteout files, then yeah, setuptools/pkg_resources should just ignore them.

[jaraco]

In this latest push, I've found the issue - the issue was that a filename was being passed ("setuptools-4XXX.dist-info") that did not exist. Therefore, isdir was false, and that led to another code path that would continue. I'm not exactly sure, but this latest change does pass the tests.

As you can see, this code is really hairy. I'm still not confident this approach is the right one.

I think more investigation is warranted into why os.path.isdir didn't produce the desired effect.

[jaraco]

In this latest commit, I investigated further and now understand why 'isdir' wasn't working as a test - it wasn't including the full path to the entry, and now including that detail, the 'isdir' test works as you had intended.

[McSinyx]

In this latest commit, I investigated further and now understand why 'isdir' wasn't working as a test - it wasn't including the full path to the entry, and now including that detail, the 'isdir' test works as you had intended.

Thanks for providing the insight!