Hi Astral, Hi uv!

[mitsuhiko]

Two weeks ago I asked the question again about What Rye should be. There has been one thing that I have not publicly shared before and that is that ever since Rye exists I have also been talking to Charlie Marsh about Python packaging and Python tooling. It turns out that we had some shared ideas of what an ideal Python tooling landscape would look like. That has lead to some very interesting back and forths. To make a potentially very long story short: Together with Astral's release of uv they will take stewardship of Rye. For the details read the blog post

[impredicative]

I currently see three roads ahead for new projects:

1. Use rye as is.
2. Use rye with rye config --set-bool behavior.use-uv=true, but which rye commands does/would this affect, and which uv commands does/would this use?
3. Use uv directly instead of rye.

Over time, the development direction will filter the choices, but for now, I can't tell which road to pick. Regarding choices 2 and 3, does Astral have sustainable funding, or will it seek to make some tools non-free in the future as say Docker did?

[zanieb]

I'll let Armin answer the Rye specific questions, but if you need all the features of rye today then uv is not yet for you.

Astral is backed by Accel and other investors. The company announcement post may be helpful. We're confident in the sustainability of our funding and we believe in providing free tools.

[mitsuhiko]

As @zanieb said, uv today is not a rye replacement yet. It's more plumbing than porcelain to stick to git terms. However over time that will change. There will be a point where the two will converge. Up to that point, rye will continue to do as it does today: be a test bed of what Python packaging can be.

As that UX becomes clearer and the feature set matures, a less brittle implementation hopefully ends up making its way into uv until rye can retire.

[spyoungtech]

Will rye continue to be MIT licensed? And, more specifically, will you @mitsuhiko continue to own rye and be able to ensure this will remain the case?

If this project is to eventually merge with uv, do we know uv is committed to also remaining MIT/Apache licensed, and do we have any commitments or guarantees for that?

I am pessimistic about the idea of companies taking over Open Source projects. I don't want to have tools I use get their license changed then force commercial users to either pay up or find something else, like what Hashicorp did to Terraform with their new BSL license.

Some day, the VC firm(s) funding Astral will be expecting returns on that investment. I don't want that to be at the expense of commercial users.

[impredicative]

like what Hashicorp did to Terraform with their new BSL license.

One good thing is that it did then lead to the creation of a Terraform fork opentofu. If Astral were to try something similar, a fork could then be a possible result as well.

Astral could alternatively get a return on the investment via an acquisition.

[spyoungtech]

It's great that enough people are committed to free and open software that OpenTofu happened, but it yet remains to be seen how this will fracture the ecosystem for users.

As one evident consequence that has already emerged, GitLab will no longer be able to ship certain terraform features and they will be removed in a breaking change from GitLab in May of this (edit: delayed) next year, due to the BuSL licensing issue. They're replacing them with OpenTofu, but it still comes with breaking changes for every user of GitLab's terraform CICD tools that are being removed.

In another example, commercial Docker users also got a licensing rug-pull for Docker Desktop and there is still no free analog for Docker Desktop.

I know there's other ways Astral plans to make money (they say they will build and sell services on top of their tools), but even Oracle did the same thing with their Java JDK, too. Travis-CI (org) said it would be free forever for Open Source projects. That turned out differently than promised.

It may be a cynical view, but I've been burned by this kind of thing too many times to not be skeptical.

[mitsuhiko]

Will rye continue to be MIT licensed? And, more specifically, will you @mitsuhiko continue to own rye and be able to ensure this will remain the case?

rye won't relicense. I hope there will be a point where uv can be a full replacement for it mostly on the hope that there won't be schism in the space. I do however recognize the risk of VC funding for developer tools (after all this is an industry I'm very familiar with). I had plenty of conversations with Charlie over the last few months and I feel quite good about their direction.

Can I exclude that they won't do something stupid in the future? Obviously not. However: the risk to users of that is very small. In case something stupid happens over there, you can bet your ass off that I will fork it. Generally though I think that there is not that much to worry about as there is only limited moat in the client side of this. Not without reason do we have hundreds of Python packaging tools.

[cnpryer]

However: the risk to users of that is very small.

I am curious how much it can affect users though. My hope is that a lot of this development pressure has a positive influence on the Python ecosystem, but I can't help but think about how deviations from any standards can potentially impact user expectations. Especially newer, unfamiliar users.

Generally though I think that there is not that much to worry about as there is only limited moat in the client side of this. Not without reason do we have hundreds of Python packaging tools.

Is it possible that's because there hasn't been something incredibly convincing to use in place of all the options? I feel like performance and innovation are very under-appreciated factors, and Astral is nailing those.

Regardless, this is all so interesting to watch. I'm very excited about what's happening.

[impredicative]

Nothing here tells me which rye commands currently map to which uv commands when using rye config --set-bool behavior.use-uv=true. Don't users deserve to know?

[mitsuhiko]

rye intentionally does not really leak out today what it uses internally because that's not part of it's defined interface. For instance today rye add uses unearth, at one point in the past it used pip install --dry-dry. In the future I hope it can use uv directly for this. Documenting what commands do internally I think only makes sense if they are becoming part of the public interface. For that reason for instance rye fmt explicitly documents that it uses ruff.