Extract Python installation code into a stand alone project

[ksamuel]

As discussed with you yesterday, I think it would be benefit to extract the part of rye that is responsible to download and install Python and expose it's API programmatically as a lib so that it could be used in other tools.

This would allow the field of Python bootstrapping to make several explorations based on a commons solid basis:

• Some tools may chose a radical simple workflow to make it dead simple to install Python for beginners, without
• Some tools may chose a GUI to make it more accessible.
• Some tools may include it into other ecosystems like VSCode, QGIS, etc.
• Maybe some installer, or packaging tools will want to use that to create a new type of Python toolkit that let you install a program and the run time for it optionally if it doesn't exist.
• CI and test tools may want to include it to standardize Python fetching. E.G: imagine tox downloading Python it doesn't have.

All that would be easier if one didn't have to include the entire project management part of rye, which is unnecessary for those steps.

There is already tremendous value for a robust, cross-plateform, unified way of installing and calling Python, and this project is a hint of that.

This would also allow for more sources of contributions, for things like:

• Improving the fallback when one download source is not available: other projects could implement alternative repositories for Python so that you can round robin to diminish load or fallback if one fails.
• Allow for private download sources for companies that want to restrict which Python is installed and from where.
• Add experimental repositories for unstable Python, or non standard Pythons distributions, the way APT add source lists.

Eventually, if this gets popular, in a few years, one can imagine proposing such tool to the core devs as the main way to install Python.

[jankatins]

This might be interesting for @jdx, the creator of https://github.com/jdx/mise

[jdx]

Unless I'm missing something mise already solves all of these use-cases. Some of them may not be documented clearly how to solve and some could benefit from DX improvements but they are all possible today I think. This is one related gap which is actually a pretty easy problem I just haven't got around to.

Lazy-loading is also possible but certainly would require executing mise in a not-obvious way. What would be more idiomatic in mise is declaring the minor versions you need and installing them ahead of time in order of preference, e.g.: python 3.11 3.12 3.10.

mise is not a "lib" but since mise and rye are both rust projects I don't see how that would make sense for either project except wrapping the rust CLIs.

mise does lack non-WSL windows support though.

[cnpryer]

I really like this idea, but wouldn't it be wise to publish a public API after the project has been somewhat stabilized? Especially the parts of Rye that leverage the Python installation logic.

Also, adding support for a public API at this stage could be a lot to ask from what is currently a one-man show.