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

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

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.

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

We do yes: astral-sh/uv#5903

Perfect, thank you!

Fixed: astral-sh/uv#6291

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

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?

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.

@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.

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.

following here @DavidVujic, we also use polylith and appreciate the work you put in to make it easier to use.

+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.

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"]

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

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

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

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.

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.

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

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

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.

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)?

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.

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

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

(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)

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.

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.

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.

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

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

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

(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 😅)

(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

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>

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

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

build and publish are available in uv now 🙂

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

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

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.

@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 ?

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

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

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

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.

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/

Hard-coding index URLs and setting the UV_INDEX_<NAME>_PASSWORD environment variables covered this use-case for me.

• https://docs.astral.sh/uv/configuration/indexes/