PrefectHQ
Make uv an optional runtime dependency
Describe the current behavior
Right now uv is a required runtime dependency but is only used in _experimental functionality here. It's also wrapped in try / except so the functionality may work without it being installed anyway.
I know that the _experimental module is used in a few places in the repo (notably here), but because uv is not a typical runtime dependency, and because it's rust based, it should be avoided if not strictly necessary.
Describe the proposed behavior
Make uv an optional dependency.
Example Use
No response
Additional context
No response
hi @BwL1289 - can you share your motivation here? when you install uv from pypi its just a pre-built wheel, It was compiled using rust, but that should have no impact on the installer.
is it causing some issue for you?
hi @zzstoatzz few motivations:
- Selfishly, I (and many distros) build libraries (and their dependencies) from source, and would love to avoid compiling
uvif possible. uvships with wheels but if a wheel is not available for a given platform, uv will be built from source, which requires a Rust toolchain- Would love to avoid an extra ~17mb in my container from
uv🙂
@BwL1289 thanks for the context - that makes sense. however, we have gradually introduced uv intentionally since we plan to use it more broadly (for ad-hoc installs and in the currently experimental features you noticed) so I'd say we're unlikely to remove it as a required dependency at this time.
that said, let's keep this issue open and if it becomes a pain point for many users then we can reconsider.
It caught my attention as well; I agree that uv has gathered momentum recently and is blisteringly fast, compared to poetry and others and uv at the moment makes very much sense especially for companies because it'll save CD/CI build time at scale, which surely is a very good motivation.
It makes sense to have uv has a dev dependency, but as an end user of Prefect, we don't really have to use uv to manage local packages right? Unless Prefect is deeply built on top of uv infrastructure, programmatically. Making it an optional run-time dependencies for end user makes sense to me.
For a personal user like me, uv isn't quiet there yet, check out 1419 and 6794. They don't have the equivalent of poetry update. Note 1419 has been there for quite some time.
uv provides uv lock --upgrade, uv sync --upgrade, uv tree --upgrade, all of which does exactly the same thing and devs aren't familiar with them. poetry is slower at times, but it is mature.
uv is great, but it is still in its early stage IMO.
@qiuxiaomu agree with you. At the least, uv should be made optional.
@zzstoatzz looks like there's some support from others https://github.com/PrefectHQ/prefect/issues/17194.
@qiuxiaomu
we don't really have to use uv to manage local packages right?
correct, us including it to power internal features (as decribed in https://github.com/PrefectHQ/prefect/issues/17194#issuecomment-2891674735) does not necessitate you use it to manage deps as a user. the issues you're linking are related to using uv as an end user. we don't require users use any specific python environment manager
Unless Prefect is deeply built on top of uv infrastructure, programmatically
prefect does and will likely expand its internal use of uv. its theoretically possible that we could disable functionality that requires uv and make it optional, but personally I'd like to see significantly more demand for it (cc @cicdw)
I'm experiencing this problem from a different angle: the uv that gets installed into my venv because I have prefect as a dependency is fighting the uv I have installed outside the venv.
It's surprising and unfortunate behaviour that requiring the prefect package can install a different version of your package manager in <venv>/bin/uv, which will be what you end up using since activating the venv put the <venv>/bin dir at the top of your PATH.
