Make Resolver.resolve take a plain list of InstallRequirement

What’s the problem this feature will solve?

Currently pip’s resolver logic is spread between pip._internal.req.req_set.RequirementSet and pip._internal.legacy_resolve.Resolver, among other classes. Regardless of the approach taken for implementing the new resolver, simplifying the interface to the resolve function will help us re-use more code before and after the call to resolve without having to consider the legacy resolution logic currently in RequirementSet.

Describe the solution you’d like

Several steps should let us get rid of RequirementSet as an input to Resolver:

1. Globally configure and manage whether temporary directories should get deleted
2. Switch all directories currently handled in InstallRequirement.remove_temporary_source to be globally managed and subject to the configuration from the previous step. Remove InstallRequirement.remove_temporary_source
3. Remove RequirementSet.cleanup_files since it only calls InstallRequirement.remove_temporary_source
4. Construct a new RequirementSet in Resolver.resolve from root_reqs and use that during resolution. Return the new RequirementSet, which callers should use for the next step of processing instead of the input RequirementSet they were using previously.
5. Instead of passing a RequirementSet to Resolver.resolve, pass req_set.unnamed_requirements + list(req_set.requirements.values()) into Resolver.resolve similar to what is currently calculated within Resolver.resolve here.

After these steps, we should be able to fork RequirementSet into one class for use with initial requirement parsing here (which could be eventually simplified to a plain list), and another class for use within Resolver (which could potentially be inlined into Resolver itself).

Alternative Solutions

• Continue using RequirementSet as the interface to Resolver.resolve and suffer since much of its logic is closely tied to the current method of dependency resolution/preparation, which would conflict with any new resolver.

Additional context

• #988

[uranusjr]

Update from the future: Turns out this is still needed because RequirementSet still conflates requirements incorrectly in various cases, and we need to reduce its usage even more for the new resolver to get what it needs.

Issues impacted by this include:

• #7096 (add_requirement() incorrectly conflates requirements with the same name, but different extras)
• #8036 (add_requirement() rejects “duplicated” requirements, even if they can be merged into one non-conflicting requirement)

[chrahunt]

One change that IMO we should make here would be to start returning a RequirementSet from the resolver, instead of assuming that the initial input was mutated. That’ll make it easier for the newer resolver to represent state however it wants and compose a RequirementSet at the end, so that it can be a drop-in replacement.

Agreed. Simplifying the interface is the main point.