Cross-python and Multi-version resolution

[nathanjmcdougall]

In the Philosophy section of the docs it is mentioned that

Bootstrapping Python via an independent tool has other benefits as well. It for instance allows much easier cross-python version testing via tox or CI.

Also, it is mentioned here that

I believe for a variety of reasons it needs to be possible for a resolver to not unify all requirements to a single version, but to support multiple independent resolutions across major versions of libraries. A future resolver should be able to permit package==2.0 and package==1.1 to both be resolved for different parts of the tree.

I am interested in how these features would potentially be implemented. This is not a feature request, I'm just trying to better understand the vision.

Here are some questions; I accept in advance that they might be misguided or might not have answers yet.

• I see the accommodation of multiple python versions and multiple package versions as related issues. In both cases we are resolving multiple dependency trees in parallel. Is that right or are these really quite separate concerns.
• I assume that in the pyproject.toml there would be some way of providing the different desired Python versions to use, and specific major library versions. Is this right?
• Would there be many lockfiles, one for each version of Python (and each major version of libraries, etc.)?
• Would there be completely separate virtual environments for each Python and package version combination?
  • I assume this could get bloated, so potentially it would opt-in behaviour rather than the default?

The use case I am thinking of is having lots of version combinations for different CI jobs. It would be great to just specify a single minimum supported Python version (e.g. 3.8) and then automatically resolve all dependencies separately for all subsequent versions 3.8, 3.9, 3.10, etc. Then, make it possible for rye to choose which tree to actually install and run (e.g. in the CI pipeline, or locally for debugging) rather than the default development version specified in .python-version.
Keen to hear thoughts about this approach and whether or not it is in line with the rye philosophy.