I tried out rye + uv on a recent greenfield project. They are awesome tools and I'm really excited about their potential.<p>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 on -- instead of, say, poetry -- or hatchling directly, following the PyPA boilerplate[1].<p>You have a way of doing local development against any Python interpreter version. You have a way of tweaking dependencies and a straightforward sync/lock workflow. 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].<p>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 build and package didn't solve a problem this project had, since the Django project wasn't being deployed via a PyPA packaging mechanism.<p>But this is probably also because the Python interpreter 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 dev-time 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] If I were to update this post now, I'd say that you could swap uv for pyenv-virtualenv + pip-tools and be happier for it, and you could swap rye for the PyPA boilerplate. That is, you could upgrade to rye, or use it from the start, if you need packaging support, or if you like its dev-time workflow.<p>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]<p>[1]: <a href="https://packaging.python.org/en/latest/tutorials/packaging-projects/" rel="nofollow">https://packaging.python.org/en/latest/tutorials/packaging-p...</a><p>[2]: <a href="https://rye-up.com/guide/commands/build/" rel="nofollow">https://rye-up.com/guide/commands/build/</a><p>[3]: <a href="https://rye-up.com/guide/commands/publish/" rel="nofollow">https://rye-up.com/guide/commands/publish/</a><p>[4]: <a href="https://amontalenti.com/2022/10/09/python-packaging-and-zig" rel="nofollow">https://amontalenti.com/2022/10/09/python-packaging-and-zig</a><p>[5]: <a href="https://github.com/astral-sh/rye/issues/793">https://github.com/astral-sh/rye/issues/793</a>