Resolve direct and pinned requirements first

[uranusjr]

Close #9185.

[pfmoore]

I'm not 100% sure how _get_restrictive_rating implements the order of preference described. That's mainly because I don't really understand what get_candidate_lookup does, though, so it's not directly an issue with this PR.

We should maybe add a documentation comment for get_candidate_lookup, and explain a bit better how it links to the preference calculation here, but that can easily be a followup (it's definitely not the worst documented bit of code in pip!)

[uranusjr]

We should maybe add a documentation comment for get_candidate_lookup, and explain a bit better how it links to the preference calculation here

Good idea, added!

[pfmoore]

Good idea, added!

Awesome :-)

Switching to an explicit check rather than using is_pinned makes it more understandable too. And I don't think it hurts maintainability as the reason we're checking for equality conditions is different here.

The subtle difference between is_pinned and the explicit check for == is "fun" 🙂 I didn't look up is_pinned on my first review, which was part of my confusion (my bad) but it wouldn't prioritise >1.0,==2.0 where the new check does. It's times like these when I think we have too much flexibility...

[uranusjr]

The subtle difference between is_pinned and the explicit check for == is "fun" 🙂

This in turn prompted me to search the code base for is_pinned usages. It turns out it is used exactly once:

pip/src/pip/_internal/operations/prepare.py

Lines 412 to 418 in e6da461

	# Unpinned packages are asking for trouble when a new version
	# is uploaded. This isn't a security check, but it saves users
	# a surprising hash mismatch in the future.
	# file:/// URLs aren't pinnable, so don't complain about them
	# not being pinned.
	if req.original_link is None and not req.is_pinned:
	raise HashUnpinned()

And I… have doubts if the implementation is correct.

[pfmoore]

And I… have doubts if the implementation is correct.

Yeah, that looks weird. This is why I tend to leave the hash-checking code to people who use/need the feature (and therefore presumably understand the requirements 😉)

[pradyunsg]

One "I'd really like to wrap this up in one go" suggestion: #9211 (comment)

Other than that, this looks great!

[pradyunsg]

Linters aren't happy, but happy to merge once that's fixed.