Package.satisfies() considers sources more carefully

[dimbleby]

Package.satisfies(dependency) has been asking the wrong question about the sources: it doesn't need the sources to be identical, it needs the package source to satisfy the dependency source.

These are different mostly because of the confusing handling of pypi and legacy repositories

• on a dependency, setting source type and source name to None means "any source is fine"
• on a dependency, setting source type to None but specifying source name means "this specific repository"
• on a package, setting source type to None means "pypi"

I've also removed the check on features: it's not wanted by callers of this method in poetry, so it was just getting in the way.

A companion MR in poetry will follow, between them these should fix python-poetry/poetry#6710

[neersighted]

In the medium term PEP 658 should hopefully be supported by PyPI, and PyPiRepository and LegacyRepository will collapse into SimpleRepository or similar, with a type of simple or index. That will clean this up quite a bit. In the medium term, how invasive would it be to make the source_type for PypiRepository pypi to reduce this ambiguity?

[dimbleby]

how invasive would it be to make the source_type for PypiRepository pypi

moderately. eg this gets written to the lockfile so it's a breaking change there.

[neersighted]

We have yet to release lock file 2.0 into the wild, so this is a very convenient time to do it.

[dimbleby]

still, seems like more effort than it justifies to me - doubly so if this is all liable to be undone by PEP691 in the foreseeable future.

If we were starting from scratch I certainly wouldn't want to use None to mean "pypi": but it is not worse than confusing...

[neersighted]

691 is the JSON format and already supported -- I think you mean 658, which is the METADATA file.

You're not wrong and your comment in this PR is more than sufficient for future code spelunkers. It was simply an observation that if you wanted to solve this wart, this is an excellent time.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information