Move _get_abstract_dist_for out of the resolver

What’s the problem this feature will solve? In order to query things like metadata for a requirement, you need to prepare that requirement (and ultimately, get an “abstract distribution” for the requirement. The function that does this is currently a method of the resolver, meaning that any new resolver won’t have access to it.

Rather than reimplement the same (or similar) functionality, move the function out of the resolver.

Describe the solution you’d like Have a function in pip’s internal API that returns an abstract distribution object for a requirement. Basically, Resolver._get_abstract_dist_for, but either as a standalone function or a method on theInstallRequirement (it’s extremely unclear to me why this isn’t a method on the requirement already…)

The new resolver will need to call this API to get dependencies for a requirement.

Alternative Solutions We could reimplement the necessary state changes independently for the new resolver. This would duplicate work, though, as well as introducing the risk of discrepancies.

The “project” model is a more ambitious refactoring that moves all of this functionaility into a stateful “project” object. This feature is a smaller, less ambitious step to achieve just what is needed right now.

Additional context This method is part of the process whereby an InstallRequirement moves through stages from just being an abstract description of what is needed to a concrete, installable object. Those state change methods should be easily identifiable and located close to each other, for ease of reference and understanding, but historically they were scattered across the codebase with requirement objects being progressed as dictated by the needs of the control flow.

Creating an abstract dist only makes sense for an InstallRequirement where we have identified the location of the code (a URL, or a local directory/file). There is an earlier state change, from “specifier” to actual object, that is much more tightly integrated with the current resolver (populate_link). This is currently all part of the one _make_abstract_dist_for method, and will need to be separated out.

It is likely that this change will need to be implemented as a series of smaller refactorings.

[chrahunt]

Strategy-wise: Another alternative is to copy useful functions out as needed. We’ve done a lot to break up situations where we had previously “de-duplicated” some code, because it is so much harder to reason about when there are multiple callers making different assumptions. If there is some common structure there that’s useful then it would be much easier to see after making a copy of the function work for the new use case in isolation.

[pradyunsg]

Honestly, I think it’s OK to break users that do fancy things like “depend on X if <state of environment>” where the state of environment could change as the package is being installed.

Basically, if we ask a package what it depends on and we get different answers on different tries, I think it’s reasonable to blame the package for doing too-smart things.