Renaming InstallationCandidate and friends

This is an offshoot from a discussion around #6607 and the future resolver work as part of #988. Also, naming things is difficult.

---

In this issue, I’m trying to jot down a few naming related concerns that I have w.r.t. the package index and resolver code in pip right now, mostly to get inputs from other folks and figure out actionable items. I want to try to make sure that no one has blocking concerns with whatever names and verbs we end up choosing here. That said, this can easily turn into bikeshedding so please don’t block suggestions unless they’re in the “no this can not work” territory.

I’ll also quickly note that I do wish that I would’ve flagged these earlier, but well, I didn’t (or I did and I don’t recall why I didn’t pursue them then). Sorry if this causes annoyance for anyone and know that that’s not the intent here.

---

I think we should rename InstallationCandidate to something that does not conflict with the “candidate” from resolvelib’s terminology. The two classes do not model the same concept and since the resolver and package-finder do pass around information, they should utilize a shared, non-conflicting vocabulary in them.

The InstallationCandidate name makes sense given pip’s current resolution strategy for something from the index is: see all candidates from the package index and choose a “best candidate”. Once chosen, this is the candidate that would be installed, ignoring any future conflicts.

However, in the resolvelib model, a “candidate” may be deselected if a conflict is found, which means a once-“selected” package index link does not always correspond to something that would be installed. It would if it is still selected at the end of the resolution process, but there are no guarantees during resolution.

If we agree that InstallationCandidate needs to be renamed, we’d also want to change some of the phrases we’re using:

• evaluate_link() needs a better description.
  • Current: returns whether a link is a candidate for install.
  • Suggestion: Evaluate if link is compatible with the current environment.
• candidate for installation -> candidate (information?) from index

---

@techalchemy and I tried to come up with a better name to avoid this ambiguity, and after a lot of mental effort, we landed on IndexCandidateInfo. Personally, I think it’s better than InstallationCandidate. It is clearer that the object is, information from the index about a “candidate” available from the index. However, we’re still using the noun “candidate” as a part of this, which I’d ideally want us to not be using here.

None the less, to structure the discussion more linearly, there’s basically 2 or 3 things I’d want to hear from interested folks on:

• Does IndexCandidateInfo sound like a better-enough name for now to do a switch “now” and avoid renaming almost every class in index.py?
• Does anyone else think there’s enough value to be had, by completely avoiding the verb “candidate” in index.py?
  • If yes, do you have any suggestions for a better noun/verb combination – for PackageFinder, Link, InstallationCandidate, “evaluate” link, “evaluate” candidate – such that we avoid using “candidate”?

[cjerdonek]

Great! I’m also okay with the idea of phasing out usages of the word “candidate” in collector.py and index.py to the extent possible, though maybe that can happen more gradually instead of trying to do it at the same time as the class rename (as there are more choices to be made).

[pradyunsg]

Also, the more I think about it, the more I think “candidate” shouldn’t be part of the class name.

Yay! We’re all on the same page. 😃

PackageLink

I agree, this is definitely the nicest name yet. 😃