GeezerVison

I've not tested this but I'm not convinced it will actually work in all cases. Our reason for this is that thanks to package upgrades and removals we'll end up with eg wheel-0.47.0.dist-info/ existing in site-packages, but it will be completely empty.

This is discovered as a distribution, and because metadata() falls back to "parse an empty string" it still has valid metadata, it's just that the metadata is empty. I'm currently hacking a test into pypa/build to check that dist.metadata.name is actually set.

I take that back, latest importlib_metadata has different behaviour and correctly raises an exception.

I must admit I don't understand the reasoning behind returning invalid distributions at all: if some empty directories that look like a dist but have no content are found, why return them at all?

I agree that globally dropping invalid distributions is the cleaner end state if the project wants that behavior. I kept this PR narrower for two reasons:

1. Distribution.discover()/distributions() is the lower-level discovery surface, and changing it to filter path entries would be a broader API/behavior change than entry_points() duplicate resolution.
2. The concrete failure here is narrower: when two distributions normalize to the same name, an invalid/empty older dist-info can win the unique() selection and hide the later valid distribution that actually has the entry point. Preferring the valid candidate only inside that duplicate-name choice fixes that failure without changing what raw discovery returns.

So this patch is conservative rather than philosophical: it avoids letting an invalid duplicate shadow a valid package, but does not decide whether invalid dist-info directories should disappear from discovery everywhere. If you prefer the broader policy, I can rework it in that direction.

I must admit I don't understand the reasoning behind returning invalid distributions at all: if some empty directories that look like a dist but have no content are found, why return them at all?

It's because the presence of the directory implies presence of a package at that version. The distribution is there even though it has no metadata. One could theoretically put a 'other-metadata.txt' in the -dist-info directory, and that would be queryable using this API. The API is trying to reflect the reality of the situation and be lenient to corruption or future evolution or extension.

In #550, I implemented an even narrower approach, which was to implement an imperfect sorting heuristic to paper over the most common case where a newer version replaces an older version but the older version metadata isn't cleaned up properly.

That approach will help the common case, but will fail to help in the case where:

• The replacement package is in fact older, so it's actually the older package that is valid and should be preferred.
• The lexicographic ordering doesn't reflect the true version ordering.

It almost makes me wonder if the sorting should instead sort by timestamp on the directory, which would more reliably reflect "newest".

I'm now reconsidering the approach in #550 and wondering if instead we shouldn't take the _prefer_valid approach.

Thanks for taking this forward in #553. That version addresses the same failure while preserving the lazy _unique pipeline and bounding the metadata-detection cost, so I’m closing this in favor of that implementation.