Rye and uv

[charliermarsh]

👋 Since we took over stewardship of Rye in February, we've been continuing to maintain the project and ship releases, but have been primarily focused on new feature development over in uv.

Rye uses uv under-the-hood, so it's also benefited from those changes (e.g., Rye's universal mode is powered by uv's universal resolver).

With the release of uv 0.3.0, uv is capable of supporting more and more Rye-like workflows. For example, uv can now download Python for you, generate lockfiles via uv lock and uv sync, and so on.

We don't plan to deprecate Rye any time soon, but our goal has always been to maintain it while we develop uv into a viable alternative. I suspect that uv can now replace Rye for some use cases, but I'm interested in hearing from Rye users: what is uv missing that would stop you from switching over? Where should we focus, if our goal is to enable smooth transition for Rye users in the future?

[mrkbac]

The new UV features look great!
One rye feature I like is the global python shim that automatically uses the venv with the correct python version. Also prevents me from using the system python, saved me a lot of headaches.

[charliermarsh]

That's a good idea. There are a few things we definitely don't support yet:

• Rye's scripts API
• Rye's sources API with different index priorities
• Anything related to Rye's shims

[zanieb]

The shim can be tracked at astral-sh/uv#6265

[kevinli1993]

Rye's sources API (ability to specify a company private repo for certain packages) is needed for our use case. I personally also enjoy Rye's shims, and think it's a major advantage over having to use, e.g., poetry shell.

[patrick-egenlauf]

@charliermarsh do you plan to include something like Rye's scripts API?

[charliermarsh]

We do yes: astral-sh/uv#5903

[ilyagr]

Update: Since uv 0.4, it supports virtual projects.

---

Does uv support virtual projects?

As best I can tell from the CLI reference, the answer is no, but it's not completely clear. The relevant passage I found after quite a bit of searching is:

uv will search for a project in the current directory or any parent directory. If a project cannot be found, uv will exit with an error.

Relatedly, I feel like your docs need some adjustment after version 0.3 and to make them easier to navigate (when looking for this kind of info, at least). The docs on project management (project concepts, projects guide) are not trivial to find, and it's hard to guess before reading them which of them (if either) will have the needed info. After reading them, they do not seem to address the question (I could have missed the answer hiding somewhere, though; I also haven't experimented with it yet and things might become clearer once I do).

Rye is a good example to follow for clear docs. It is easier for rye to achieve that, since the tool has a more focused scope, but I'm sure that this is doable for uv too. I guess this will be my last bit of feedback for now: uv can do a lot of cool things, but I think the UI and docs could do a better job of making it easy to discover just the right set of tools for each of the use-cases (e.g. "set up a pyproject.toml to manage the MkDocs dependencies for building docs for a non-python project, as well as a workflow to make it easy for Rust developers to run MkDocs", in my case).

[charliermarsh]

Perfect, thank you!

[charliermarsh]

Fixed: astral-sh/uv#6291

[quodlibetor]

For people coming to this discussion now, uv 0.4 made significant improvements and changes to the virtual package/no-code package feature set: https://github.com/astral-sh/uv/releases/tag/0.4.0

[DynamicalSystem]

Still continuing my migration to uv from rye. I'm trying to use uv init --virtual but the --virtual option doesn't seem to do anything, there's no mention of it as an option in either the webpage docs or the man page and the folder it produces has a hello.py file which seems redundant. I can see that 6720 removes the concept of virtual workspaces from the virtual|explicit workspace roots explainer and refers to it as legacy... and even the Workspace Roots section mentioned above has been excised.

Has --virtual been deprecated or am I doing it wrong?

[charliermarsh]

Yeah we removed the virtual concept in favor of “projects that aren’t packages”. The app flag to uv init will create a project that uv will not treat as a package, so it won’t be built and installed into the environment, like Rye’s virtual workspace root concept.

[jessekrubin]

FWIW: the most alarmingly great thing about rye is that it works just as good on windows (many python things don't work good on windows). My place of work develops for rhel and windows, so having both "work good" is crucial.

[shamrin]

I am a bit worried that you plan to make people switch from rye to uv eventually. The confusion has some potential to end both projects. (Perl 6 as the most egregious example.)

Have you considered for the future to simply rename uv to rye and make the most important sub commands compatible?

[mitsuhiko]

@shamrin my original goal was (unless a better plan emerges) to have a "final" release of rye eventually that just dispatches to uv under the hood and upgrades the project if necessary to uv tool conventions to make the upgrade transparent.

[gwdekker]

Probably a bit lower on your list, but we use the polylith plugin for rye to make our monorepo setup work: https://github.com/DavidVujic/python-polylith-example-rye

apart from the nice tooling the polylith CLI offers, key functionality and setup here is:

• Allow for relative paths (as far as I can see uv already can do that)
• Allow for a setup where there is one root pyproject.toml and also pyproject.tomls in the /projects section for deployable units, and one lock file at the root of the repo.

I am not a rust programmer, so maybe this is all already covered by the workspaces concept?

[DavidVujic]

I'm happy to hear about the Polylith usage! I have begun to look into the workspaces feature of uv (and I guess also Rye), and how it can be combined with the Polylith tooling.

[bluss]

I think rye init --script is a minor one that would be nice to have in uv, because it shows by example how to set up a project with executables.

Edit: Uv now does this for uv init --app --package

[my1e5]

+1

As it currently stands, starting from

uv init myproject

All you technically need to do to make your project executable is to add

[project.scripts]
myproject = "myproject:hello"

to the pyproject.toml file. Then

$ uv run myproject
Hello from myproject!

But would be nice if there was a --script flag that set this up and did whatever the best practice is in terms of layout. I know that Rye also creates a __main__.py file and uses a main function in __init__.py instead of hello.

[ethanmsl]

Rye's support for Rust modules out-of-the-box is quite nice. It was something that I'd love to see get even more love. Any chance uv will focus on supporting this as well. It enhances both languages considerably I feel, if that friction is removed in what's likely a future standard too.

I'd like to be able to have a python directory with notebooks (a la Zed repl) inside my rust repos and be able to setup rust in my python repos to add code easily. And I think reducing that friction would bring a lot to the table.

(Nice work on supporting single-file scripts, btw. I'm looking forward to that coming out of nightly in Rust for the 2024 version.)

[vivienm]

Rye's support for Rust modules out-of-the-box is quite nice. It was something that I'd love to see get even more love. Any chance uv will focus on supporting this as well. It enhances both languages considerably I feel, if that friction is removed in what's likely a future standard too.

This seems to work by adding the following lines to the pyproject.toml file (as rye does):

[build-system]
requires = ["maturin>=1.7.0"]
build-backend = "maturin"

[tool.maturin]
python-source = "python"
module-name = "my_project._lowlevel"
features = ["pyo3/extension-module"]

[bluss]

A maturin template is now implemented in uv and will be in the next release.

[jgeralnik]

I just migrated from rye to uv. It was relatively straightforward - got most of the way there by replacing [tool.rye] with [tool.uv] in pyproject.toml

The docker build required slightly more changes because previously I was copying in rye's requirements.lock and installing it with regular pip without needing rye in the build process at all. The docker guide (once I found it) was straightforward to follow. I did discover that I could just use uv compile and continue using raw requirement.txt files in my docker image but uv is so much faster that I left it that way anyways.

Likewise the github action was straightforward to set up by following the guide as well.

[jgeralnik]

One thing I would add to the Docker guide is to run uv sync --frozen --no-dev instead of just uv sync

[nickchomey]

Is there any doc available for migrating from rye to uv?

[uwu-420]

Really excited to make the switch to uv! Thanks for all the great work :)

If I understood the docs about dependencies and alternative indexes correctly, I can only specify the source for a specific dependency and I could set UV_EXTRA_INDEX_URL but there is no way to add additional indexes like I can do with rye? See here

[[tool.rye.sources]]
name = "pytorch"
url = "https://download.pytorch.org/whl/cpu"

I have a bunch of dependencies from my own index and it would be cool to just include it as an additional source like I can do with rye. Or are there some bad consequences when doing that? Would be interested if someone else would like this feature.

[charliermarsh]

Yeah that's correct -- we only support the pip-like --extra-index-url API. We do want to add an index priority API but we cut it from scope for the release -- hopefully will come soon.

[Systemcluster]

This is a very important feature for anything related to GPU compute (language models etc.) where libraries like pytorch provide different sources for different CUDA versions including subdependencies.

[JonZeolla]

I'm in the same boat and this would be quite valuable to me. Similarly we are looking forward to index pinning

[ciscorucinski]

On Linux, the thing that has stopped me the most from updating Python has been the worry of accidentally overwriting my system Python. I want to install every major point release, and keep them updated. I also would potentially like to try out new beta versions if needed, but I want all of these installs to be easily discovered within PyCharm, even with new projects.

It seems like Rye might allow this (or a subset) via rye toolchain ..., right? I just heard about this Rye feature earlier today. But is this also possible (or extended) under uv?

[bluss]

See the uv python subcommand, it's basically the same feature

[teroshan]

I haven't migrated to using uv yet, however I have also been a user of rye toolchain to manage my Python installations.

It looks like uv supports this use case via uv python.

Currently the only think missing is something that works like the rye shim, but it is planned.

[ciscorucinski]

Currently the only think missing is something that works like the rye shim, but it is planned.

This is what is preventing it from becoming globally available to PyCharm? Basically this shim would be just like downloading Python from the official source and installing it in the correct directory (to not override system python)?

[scottyeager]

It's worth noting that both Rye and uv install portable builds that deviate somewhat from what you'd get from a distro package manager or building from source (such as via pyenv). You can read about those builds and their quirks here.

The shim feature enables automatic and transparent use of different versions of Python in different shell contexts. That can be per folder and/or globally. Shims only affect users who enable them, so anything root or other users do with system Python will be unaffected.

Pycharm has its own feature for using different Python versions with different projects. That should work with any solution for getting different Python builds, be it uv, Rye, pyenv, or something else. You just need to know the paths.

[asmith26]

Does uv support https://github.com/dhatim/python-license-check?

In particular, because rye outputs standard requirements.txt files, this lib works well with a rye project. Thanks!

[asmith26]

Looks like this has just been added, many thanks! https://x.com/charliermarsh/status/1829620595048468480

[varioustoxins]

Build and publish? Or have I missed something?

[zanieb]

Definitely on the short-term roadmap. Documented as not supported at https://docs.astral.sh/uv/guides/publish/

We're tracking at astral-sh/uv#6278 / astral-sh/uv#1510

[boenshao]

Would uv support commands like fmt and test in the future? Or will it focus on managing the Python environment?

[my1e5]

(not a direct answer to your question, but for those worried about losing fmt and test you can still get this kind of functionality by adding ruff and pytest as dev dependencies like uv add --dev ruff. Then you can add a task runner library (see astral-sh/uv#5903) and assign a key like fmt = "ruff format ." in your pyproject.toml file.)

(Or you could install ruff as a global tool. But I like keeping the ruff version and dependency contained within the pyproject.toml on a per project basis. In fact, I would do this for my Rye managed projects as well. The built-in Rye ruff version was always a bit behind the latest release for example)

[anna-hope]

I really want uv to ship with support for uv fmt, uv test, and uv lint out of the box, and use Black, pytest, and Ruff for those, respectively — just like Rye. One of the best things about Rust and Cargo is that they standardize the tooling for formatting, linting, and testing the project, so people don't have to pick from a myriad of different formatters, linters, and test frameworks just to get started. Python has had too many options for each of those tools, and I don't think that forcing choice is good here — I've worked on projects where people spent way too much time figuring out (and sometimes arguing) which one to use. And even if Black and pytest have become the de-facto standard (and I hope Ruff gets there soon, too), having to manually install and configure them with uv — and then needing a longer command to run them — adds extra steps and increases cognitive load. If people want to use something else, like pylint, or unittest, then that can be supported as a custom subcommand. But I think the Python community really needs good default tooling that doesn't require extra steps or configuration to use.

In Rust, I can open a project, and run cargo fmt or cargo test or cargo clippy, and in almost all projects, it will automagically know what to do and where to find my code. Rye provides that, too. But uv currently doesn't. I want to promote uv as a definitive project management tool, and a solution to the (honestly often soul-crushing) work of managing Python projects, so that someone can do uv init and get everything they need, and not have all the enormous mental overheads we have with existing tooling that isn't Rye.

[ryan-minato]

From my perspective, fmt, test, and lint should be part of the default template of uv, but it should also allow users the flexibility to replace them if needed. While it's fine to provide default settings, forcing a specific tech stack on everyone isn't ideal.

Currently, rye defaults to using pytest, but it doesn't create a tests folder. A better practice would be to automatically add pytest to the dev-dependencies section and provide a shortcut under something like tool.rye.scripts (well, custom commands are on UV's TODO list), while also creating a default tests folder.
If someone must using unittest, they could simply adjust the command in tool.rye.scripts instead of having a redundant top-level subcommand that they'll never use.

If compatibility must be considered, perhaps uv test could be mapped to uv run test.

btw, I completely understand the desire to escape the never-ending decisions around toolchains (especially since I sometimes have to do front-end work, and the front-end toolchain is a real nightmare). However, in my case, mandating the use of ruff hasn't actually eased the debates within my team. We still argue over whether boolean parameters should be allowed, whether it's okay to write error messages directly inside parentheses, and whether assert statements should be permitted.

[DynamicalSystem]

Plus one for uv test --package <package>. I have started to migrate rye functions to uv and this is the immediate sticking point in my makefile.

[sena-nana]

Will uv support rye.virtual configuration? I'm not sure there is a configuration that will accomplish the same thing. I don't want to install the project itself into the environment.

[baggiponte]

I think you can since uv 0.4.0! https://docs.astral.sh/uv/concepts/projects/#creating-projects

[SamoylovMD]

I personally use Rye to build wheels and publish them to pypi (rye build and rye publish correspondingly). I don't see such functionality in uv, does that mean you're planning to leave building and publishing for external tools like hatch? In this case this will go against Rye purpose as being the single entrypoint for managing Python projects as we'll need again this multiverse of tools instead of one single solution.

[dflock]

They are planning to support both uv build and uv publish: #1342 (reply in thread)

[AucaCoyan]

A low hanging fruit is that uv init doesn't create a git repository (I couldn't find it on the uv init --help), but rye init does.
It's not stopping me at all, but would be a great feature to have if we want to have cargo in python 🥰

[charliermarsh]

There's an open PR for this thankfully: astral-sh/uv#5476

[benrutter]

For me, aside from liking the python shim (which somebody else has mentioned) the main thing stopping me from swapping to uv (from rye) is for team projects where rye is working well, the different locations for dev dependencies in pyproject.toml mean I'd need to convince the rest of the team to swap from rye to uv too, which isn't the easiest argument when rye is currently working great for everyone.

It's kinda caused by python not having a standard dev requirements protocol, but it would be amazing for some kind of magic setting to tell uv "no actually look at this section for dev requirements instead".

[benrutter]

(even better would be if the python community standardised on a way of capturing dev requirements, but that's probably a lot harder to achieve as a single project than a settings option 😅)

[harkabeeparolus]

(even better would be if the python community standardised on a way of capturing dev requirements, but that's probably a lot harder to achieve as a single project than a settings option 😅)

Guess what, they did, and it's done! 👍🏻 PEP 735 – Dependency Groups in pyproject.toml

[AnirudhG07]

I just found out rye and uv, and from the conversation, it seems rye and uv have both its pros and cons, and uv being under development, may potentially replace rye(?)... So should i start using uv directly? I only need for basic python packages, not yet building large scale projects...

[phi-friday]

If only build, publish were added, I would change it to uv.
It would be nice if the tool.rye.virtual option was also available, but it's not required.

[phi-friday]

I tried migrating from rye to uv.
I needed the following features more than I expected

1. tool.rye.scripts
2. rye version <some version>

[my1e5]

tool.rye.scripts-like functionality can be obtained using 3rd party libraries - see astral-sh/uv#5903

[phi-friday]

One of the last features I needed was to generate a requirements-dev.txt or requirements-dev.lock containing tool.uv.dev-dependencies.

I understand that this is not yet supported.
astral-sh/uv#6429
astral-sh/uv#6007

[bluss]

build and publish are available in uv now 🙂

[bluss]

And uv export can generate requirements files -- with dev, without dev, only dev, etc.

[nickchomey]

Is there a doc for migrating from rye to uv? It should be a relatively simple process, but would still be good to have instructions

[jgeralnik]

No doc, but really - just place dev-dependencies under [tool.uv] instead of [tool.rye] (didn't need any other settings from there) and then run uv sync.
The more complex part if if you're doing something else with your project (running in docker, publishing to pypi, etc). If you have any specific questions I'd be happy to help

[lucianosrp]

Also, if that helps, I wrote a simple tool to migrate from rye to uv and I am planning to keep track on the different changes.
For now, it only converts to uv~0.3, but I will be adding the conversion of tool.rye.virtual relatively soon.

[mandarvaze]

@jgeralnik I replaced tool.rye with tool.uv in my pyproject.toml and executed uv sync
I got unknown field virtual`` - because I have the following entry

[tool.rye]
managed = true
virtual = true
dev-dependencies = [
    "ruff>=0.5.5",
    "pytest>=8.3.2",
]

Any suggestions ?

[lucianosrp]

@mandarvaze, you should be able to replace virtual=true with package=false
I made an "unofficial" conversion table between rye and uv here

[mandarvaze]

@lucianosrp Thanks. The error went away after making changes suggested by you.

[Super1Windcloud]

I think that uv compared with rye, uv's function and feature is more simple and practical

[ryan-minato]

The feature of generating the project layout for pyo3 is very important to me—it was almost the sole reason I switched from poetry to rye. Some of my work-related projects are highly performance-sensitive, and pyo3 provides significant benefits. However, before using rye, I couldn't find a tool that allowed me to initialize a project in under 30 seconds.

By the way, I’ve been using uv to manage my experiments because its locking mechanism is simple, intuitive, and fast.If uv had better support for pyo3, I would have switched to uv without hesitation.

[harkabeeparolus]

This is available now: uv init --build-backend maturin --app foo

[0x00cl]

I think that uv and rye docs should point to some of their differences and overall goal. I was a bit confused on why they were developing two projects, and which one should I use, specially because the homepage of each tools describe them as the same thing.

rye:

Rye is a comprehensive project and package management solution for Python

uv:

An extremely fast Python package and project manager, written in Rust.

The only answer is from astral blog which I doubt developers will read or even find.

We'll maintain Rye as we expand uv into a unified successor project, to fulfill our shared vision for Python packaging.

Letting developers know uv is the intended successor should cause less problems in the future.

EDIT: I want to clarify that the docs should contain that information and not hidden behind blogs.

[impredicative]

Letting developers know uv is the intended successor

If rye becomes a progressively thin layer to uv while maintaining its functionality, that won't be so bad either.

[chaneyzorn]

If rye becomes a progressively thin layer to uv while maintaining its functionality, that won't be so bad either.

If Maintainer asked this:

what is uv missing that would stop you from switching over?

Why not just announce uv is the intended successor?

Speaking clearly and firmly can avoid many problems.

[zanieb]

It is the intended successor. I think this has been fairly clearly stated. e.g. from Armin https://lucumr.pocoo.org/2024/8/21/harvest-season/

[Kristina-Pianykh]

The great feature I thought rye has is the string interpolation for index URL in pyproject.toml. I see this issue has been raised and tracked in uv: astral-sh/uv#5734
I'm setting up a project for an internal library for my team and passing the argument for the alternative index with the whole link seems cumbersome to me as opposed to storing it in pyproject.toml. Every time I need to add or remove a package from deps or perform a sync, I have to provide a long index url and make sure to paste my credentials correctly so this is just jarring in usage. Until uv implements this feature, I will have to push for using rye.