Rye Next Steps

[mitsuhiko]

The feedback and interest in rye has been overwhelming. At the moment I'm still not entirely sure what to do here because this project as mentioned originally was not really a thing I expected to release. My goal is to figure out what a reasonable course of action is. For this purpose I want to better outline what I wish Python packaging could look like.

I hope that this project can push things forward, but I'm conscious of the fact that projects came before this with very much the same desire. So here is what you can get to expect next:

1. A written summary of hypothetical plans of what rye could look like
2. Something like a todo list of what needs to be done in my opinion in the ecosystem to support something like rye
3. At least a barebones mock-implementation of some of those ideas with rye on top of existing tools behind the scenes.

Not only has there been a lot of community interest in rye, it has also resulted in some very fruitful and healthy personal conversations, some of which suggest that there is a healthy appetite in "fixing packaging" that can be channeled. I hope that within the next two weeks I have something more substantive to share what one can expect here.

[Stanzilla]

Maybe join forces with @charliermarsh / https://astral.sh?

[cnpryer]

Yea to be completely honest I'm expecting something from them, but until then I think it's still a good idea to keep fleshing this out.

[Stanzilla]

Yea to be completely honest I'm expecting something from them, but until then I think it's still a good idea to keep fleshing this out.

Well yes which is why it could be beneficial to just start collaborating now instead of then again ending up with 2 solutions.

[cnpryer]

I'd agree (I'd prefer if we all work together on this), but there are also some features of the Cargo-like experience that could be implemented pretty differently between each tool.

An example would be using https://github.com/indygreg/python-build-standalone or going with PyBI. Because it's Python I think there's still a lot of grey area to tinker with.

So there are still valid experiments that could be done in parallel, and I think that kind of "market" of solutions will ultimately produce a better tool in the end. It's also probably unrealistic to expect everyone to come together on this.

[Stanzilla]

I'd agree (I'd prefer if we all work together on this), but there are also some features of the Cargo-like experience that could be implemented pretty differently between each tool.

An example would be using indygreg/python-build-standalone or going with PyBI. Because it's Python I think there's still a lot of grey area to tinker with.

So there are still valid experiments that could be done in parallel, and I think that kind of "market" of solutions will ultimately produce a better tool in the end. It's also probably unrealistic to expect everyone to come together on this.

Oh I did not mean that everything has to stay like rye works now etc, just that the two teams should work together on it. Design can and should still be changed if needed.

[astrojuanlu]

People saying "you X and Y should collaborate" just underestimate how difficult it is to, well, collaborate with another human, let alone establishing collaboration between a solo developer and a startup, with totally misaligned priorities and incentives.

[ksamuel]

That's fantastic news.

One important thing is that right now rye is solving two problems at once, bootstrapping python and managing the python project.

While I see the value of having both solved by the same tool, I also see immense value in having the python bootstapping solved by a stand alone tool.

Since you are going to ponder the whole situation, may I suggest to extract the bootstrapping part into a stand alone project that rye would use under the hood?

[ifeeltiredboss]

So basically pyenv all over again?

[ksamuel]

So basically pyenv all over again?

Quite the opposite. The beautiful things about rye is that it avoids many of the pitfall of alternative tools (hence https://bitecode.substack.com/p/why-not-tell-people-to-simply-use).

For pyenv in particular:

• rye is written in rust, meaning it can cross compile a stand alone executable to be easy to install on most popular platform. No need to expect to pip install it, use homebrew or something else, which are a huge source of errors for a lot of people.
• while pyenv requires to compile python on your machine, a process that can fail in a thousand ways, rye ships pre-compiled binaries.
• neither pyenv nor rye are currently officially supporting windows, but given the author track record, it's very likely there will be one for his project (not wanted to talk for him though)

[ketozhang]

We could also request pyenv or create a pyenv plugin for compiled binaries (quick search I found one thread).

Your first point is not something I'd put importance in, but I understand some may. Your last point, there are Windows installation for pyenv

[selay01]

The biggest difference between rye and other similar tools is that it is based on Rust, which means it can easily bootstrap the Python interpreter. Rye solves the chicken-and-egg problem, which other similar tools do not have, so there is no doubt about whether it should exist. Rye and PEP 711 - PyBI may become good partners in the future.

Rye provides a one-stop experience for bootstrapping the Python interpreter, managing Python environments, managing package dependencies, and packaging and publishing packages. Currently, it seems that other similar tools do not focus more on packaging as an application. If Rye can integrate PyInstaller or the official zipapp into its one-stop experience, it will promote the evolution of Python distribution.

Maybe, using Rye to conveniently package everything a project needs, including but not limited to the Python interpreter, standard library, and other dependencies, and quickly restoring them, can become another solution for Python distribution or project sharing.