Taking it Further (Help Needed)

[mitsuhiko]

I developed Rye primarily for my personal use, and it largely achieves what I intended. It makes me happy personally. However, its current state is not sufficiently advanced to be broadly valuable for the Python development community.

That said, I think some parts of it work better and others not so much. Which is a long way to say that it requires some further discussions of what to do with it.

Separating Fetching?

What I think it does really well is to just give you Python. When you use rye, it does not just help you manage your Python projects, it also just gives you a Python installation ready to go, no matter which platform you are on. That is something that has been enabled thanks to the amazing python-build-standalone Python builds by @indygreg.

One thought that I had was to separate out the shim business from the rest of rye? Decision very much not made.

Missing Piece: A Resolver

The biggest issue with Rye is that Rye just uses pip-tools behind the scenes. When I originally built it (long before open sourcing) I was just hoping that the ecosystem will eventually move up and settle on a good resolver and installer. Unfortunately that did not happen, and nothing really materially improved over the last year. We have two larger package managers with PDM and Poetry but pip is where it was before, and not much has changed. I can see that there is stuff cooking though, as for instance Prefix is now also trying to poke around in that ecosystem as well and I know from others too.

I am absolutely not willing to invest time into this myself because this is a many people job, and I just do not have the time for it.

Pipedream: Multi Version Support

Originally my next step plan for Rye was to revive my multi-import system from way back when. My theory is that Python really needs multi-version support if more complex resolvers become commonplace (that means to be able to support two versions of a library at once in a project, eg having both openai==0.9 and openai==1.0 available). This was also recently brought up again on Twitter and I very much hope that it can be a reality. However multi-version support needs primarily some agreement by a resolver and installer where to put different versions of libraries.

Once a resolver is in place, I really would love to see if multi-version Python can be made a reality.

Future: Help Needed

Rye remains largely as it began—a solo endeavor. Due to time constraints, I'm unable to advance the project significantly on my own. Its future is uncertain, and its continuation hinges on collaborative support. If you're keen to dive in and contribute, your involvement could be what is needed. The success and evolution of Rye now largely rely on expanding the team beyond just myself. If you're interested in being a part of this journey, please reach out. Your help could shape the direction and capabilities of Rye.

---

Since I did not have the resources over the last year I wanted to have, I put some of my ideas into writing instead:

• The Rye Philosophy
• The Challenge with Environment Markers
• What a Meta Data Server Could Look Like
• The Challenges with PEP 508 for Rye

[simonw]

Suggestion: clarify the meaning of "multi-version support" here. I'm 95% confident this means multiple versions of the same Python package - eg having both openai==0.9 and openai==1.0 available in the same virtual environment, such that different software within that environment can import specific versions.

I think it would be good to clarify, that in this issue description, to make absolutely sure nobody misunderstand, and things you're talking about Python 3.8 and Python 3.9 at the same time.

You could link to this too: https://github.com/mitsuhiko/multiversion

[mitsuhiko]

@simonw good point. I clarified this and linked to it.

[tusharsadhwani]

I had already built yen which serves as a static binary CLI for fetching Pythons.

I plan on maintaining it in the long term, so maybe that can serve as point 1.

[ofek]

FYI I view Hatch as one of the main tools now that will forever serve that purpose https://hatch.pypa.io/latest/blog/2023/12/11/hatch-v180/#python-management

Whenever there are official releases (that are also built as optimized as python-build-standalone) then I will switch to that as the source.

[ischaojie]

Thanks to mitsuhiko for creating rye, and I'm happy to continue to dedicate my time to rye (as I always do) to help with problem-solving and new feature additions.

[zen-xu]

consider rip as a resolver？

[geoqiao]

As a Python beginner, I have tried Python package managers like pip and conda, but I found that they all have some drawbacks. Pip often fails to install packages, which can be very frustrating for a beginner like me. Conda rarely fails to install packages, but it can be difficult to find packages that are compatible with the latest version of Python.

Rye solves all of the problems I encountered with pip and conda. It is easy to use and has a clear and concise syntax.

I am excited to see how Rye continues to develop. I hope that it will become the standard Python package manager for beginners and experienced users alike.

Thanks a lot!

[mitsuhiko]

One of the things that I really need help with is improving the documentation. I tried to make some improvements now by documenting the individual commands, but there is a lot more that is needed to turn this into something user friendly.

[aneeshdurg]

I've been thinking about multiversion support for a while, but my approach was pretty different (built on top of virtual environments). I put some of those thoughts into a poc: https://github.com/aneeshdurg/multiversionpython

Regardless of the approach, I think it's a worthwhile problem and I'd be happy to help with it! (Also, rye is super cool!)

[cnpryer]

One of the things that I really need help with is improving the documentation. I tried to make some improvements now by documenting the individual commands, but there is a lot more that is needed to turn this into something user friendly.

Is there value to having a tracking issue for documentation needs? These are low hanging fruit that, given sufficient direction, first-time-contributors can assist with pretty easily.

[mitsuhiko]

Yes, but also part of the challenge is that the docs look quite okay until you try to read it :) But I will try to give it an attempt. I started with some basics here: https://github.com/mitsuhiko/rye/issues/599

[dsp]

I guess the resolver part is done :)