Revert the part Candidate.dist is being eagerly computed

[uranusjr]

One of the changes in #9264 was to make the dist property eagerly computed since I thought the lazy candidate sequence would be good enough. But it turns out that’s not the case, since in --upgrade mode, the iterator held in FoundCandidates is actually eagerly consumed:

pip/src/pip/_internal/resolution/resolvelib/found_candidates.py

Lines 27 to 46 in 2b0b426

	def _insert_installed(installed, others):
	# type: (Candidate, Iterator[Candidate]) -> Iterator[Candidate]
	"""Iterator for ``FoundCandidates``.
	This iterator is used when the resolver prefers to upgrade an
	already-installed package. Candidates from index are returned in their
	normal ordering, except replaced when the version is already installed.
	Since candidates from index are already sorted by reverse version order,
	`sorted()` here would keep the ordering mostly intact, only shuffling the
	already-installed candidate into the correct position. We put the already-
	installed candidate in front of those from the index, so it's put in front
	after sorting due to Python sorting's stableness guarentee.
	"""
	candidates = sorted(
	itertools.chain([installed], others),
	key=operator.attrgetter("version"),
	reverse=True,
	)
	return iter(candidates)

So this PR restores the previous lazily-calculation of the dist property. I’m honestly not sure why we need to eagerly consume the iterator, and will do more experiements to see whether that can be eliminated. But this is the shortest route to fix 20.3.2 and should be published first.

[pradyunsg]

FAILED tests/functional/test_new_resolver.py::test_new_resolver_skip_inconsistent_metadata

FYI

[uranusjr]

That’s why we had to resolve the candidate eagerly—otherwise we don’t know where we can catch this exception. Maybe we should do #9288 instead?

[pradyunsg]

Maybe we should do #9288

This is #9288. ;)

[uranusjr]

#9289. Too many open tabs 😩