Abstract away AbstractDistribution in higher-level resolver code

[McSinyx]

This (hopefully) simplifies the implementation and makes the logic a bit more obvious.

[uranusjr]

One potential advantage I can think of to return an AbstractDistribution is we can generate better error messages by inspecting (or reflecting on) the returned instance. The preparation method is lost if we return pkg_resources.Distribution directly. I am not sure if that would ever be done, however, so this change makes sense to me.

[chrahunt]

This is going the wrong direction, IMO. If we're trying to trade out pkg_resources and hide details about how distribution metadata is retrieved, then we need a wrapper around the underlying Distribution.

[pradyunsg]

@chrahunt #8114 introduces that wrapper.

IMO it makes sense for us to migrate away from returning AbstractDistribution out of RequirementPreparer -- we always call get_pkg_resources_distribution on the returned AbstractDistribution basically immediately and, as @uranusjr noted, I don't think we'd be introspecting the type of the AbstractDistribution for error messaging (or something similar) anytime soon.

[chrahunt]

I'd like to point out #8448 as an example of a clean approach to the kind of issues we're facing in #8638. I think this is a promising direction design-wise, and it depends on us having our own type to contain the "downloaded" state (AbstractDistribution). Any approach that lets us hide some details from the resolver (a plus in my book) will probably take a similar form.

I see how this change makes things a little simpler, but I think leaving AbstractDistribution in place for now will help guide us towards approaches that are simpler overall.

[pradyunsg]

I see how this change makes things a little simpler, but I think leaving AbstractDistribution in place for now will help guide us towards approaches that are simpler overall.

I can get behind this sentiment.

FWIW, I'd spotted this simplification a while back when I'd created the operations.prepare module and had forgotten about this until @McSinyx brought this up in one of our discussions. In the original meaning of "prepare" (which was handle download + unpack + generate metadata + archive/place in correct location) this is definitely a simplification I like. However, as we decouple those steps now, I agree that this additional layer of abstraction is OK to keep as we do this, even if it may feel redundant right now.

[chrahunt]

I missed (at least) one thing here: if we want to persist state that the Candidate and Resolver don't know about, we can always do it on the InstallRequirement. Given that, and the statement from @pradyunsg above about #8114, I think this change is OK. 👍

[chrahunt]

I sense implied approvals for this approach from @pradyunsg and @uranusjr, and likely my concerns holding this back, so I can merge it.

Thank you for your patience @McSinyx!

[McSinyx]

Thanks for the merge and the explanation from everyone here.