Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I tried out rye + uv on a recent greenfield project. They are awesome tools and I'm really excited about their potential.
For me, rye (+ uv underneath) has perhaps the perfect workflow for an open source Python project. So I'm definitely using rye for that from now in -- instead of, say, poetry -- or hatchling directly, following the PyPA boilerplate[1].
You have a way of doing local development against any Python interpreter version. You have a way of tweaking dependencies. It all works atop "standard" PyPA infrastructure like pyproject.toml. You have a single command to build[1] project artifacts, like wheels. And you have a single command to publish new artifact versions to PyPI[2].
I think if you're doing local development on a project that is not meant to be published to PyPI, like a private Django project, then whether to use rye becomes more of a debate. For example, for a Django project I'm working on, I decided to just use uv directly, along with a Makefile. This is because during development of a Django project, I preferred to just use a plain requirements.txt (really, requirements.in) file, avoid the sync/lock workflow that rye imposes, and avoid the need to use something like rye run. And rye's ability to package didn't solve a problem since the Django project wasn't being deployed via a PyPA packaging mechanism.
But this is probably also because the Python interpreter/venv management problem, for me, is already handled by pyenv. I think if you're not already a pyenv user, rye is even more appealing because it handles "all" of the Python issues -- interpreters, requirements/dependencies, and packaging/publishing. (As well as a number of other standard issues besides, like testing, linting, and formatting.) But, in my case, I could hand venv management to uv, and then make dependency management part of a larger Makefile for my Django project, including custom linting, testing, and deployment steps. I wrote a little bit about my high level thoughts on Python packaging and dependency management, though this post was written before rye and uv were out.[4]
I'll also say, I found a little bug in how rye (+ hatch) interacted with my local git setup, and reported it to the rye team, and they helped me get to the bottom of it rather quickly.[5]
[1]: https://packaging.python.org/en/latest/tutorials/packaging-p...
[2]: https://rye-up.com/guide/commands/build/
[3]: https://rye-up.com/guide/commands/publish/
[4]: https://amontalenti.com/2022/10/09/python-packaging-and-zig
[5]: https://github.com/astral-sh/rye/issues/793
It’s worth calling out that it’s still early days for Rye. The ownership recently transitioned from Armin Ronacher to the team that develops ruff (https://astral.sh). No doubt limitations exist today, but it’s going to look a lot more like cargo as they put out more releases.