- uv is aware of your dependencies, you can add/remove development dependencies, create group of development dependencies (test, lint, dev, etc) and add or remove those and only those at will. You can add dependencies and optional dependencies for a project as well, think my_app[cli,standard]. You don't need to have different requirements.txt for each case nor do you need to remove things by hand as you'd do in pip, since it doesn't remove deps when you remove a package for example. As a result, you can remove {conda,poetry,...} from your workflows.
- uv can install python and a virtualenv for you. Any command you run with `uv run` from the root of a repo will be aware of its environment, you don't even need to activate a virtualenv anymore. This replaces {pyenv, pyenv-virtualenv, virtualenvwrapper,...}.
- uv follows the PEPs for project config (dependencies, optional dependencies, tool configs) in the pyproject.toml so in case uv dies, it's possible to migrate away for the features are defined in the PEPs. Which is not the case for say, poetry.
- uv has a lock file and it's possible to make deps platform specific (Windows, Linux, MacOS, etc). This is in compliance with a PEP but not supported by all tools.
- uv supports custom indexes for packages so you can prefer a certain index, for example your company package index or pytorch's own index (for ML work).
- very fast, makes local dev very seamless and is really helpful in CI/CD where you might just setup and tear down python envs a lot.
Also, the team is responsive on Github so it's easy to get help.
Does this also replace, or work well with tox? We currently use it to run basic CI/local workflows (`tox -e lint` for all linters, `tox -e py310`, `tox -e py312` to run tests suites on chosen interpreters' environments), and to set up a local environment with package installed in-place (so that we can run `myprogram -arg1 -arg2` as if it was installed via `pip`, but still have it be editable by directly editing the repo).
With how much the ecosystem is moving, I don't know whether the way we're doing it is unusual (Django and some other big projects still have a tox.ini), obsolete (I can't find how ux obsoletes this), or perfectly fine and I just can't find how to replace pip with ux for this use case.
I'm not personally releasing a ton of internal packages where I work but I know of https://github.com/tox-dev/tox-uv. Haven't tried it yet though but it seems to do what you want. I also saw that nox (tox but in python instead of a tox.ini file https://nox.thea.codes/en/stable/config.html), is supporting uv from what I understand.
Uv works fine with tox, but have you tried nox? I only dipped my toes in tox, but I found nox around the same time and gravitated to it. I replaced PDM's "scripts" concept with nox sessions. I have a project where most of the functionality is nox sessions I call in CI pipelines. Writing sessions in pure python opens so many doors.
- uv can install python and a virtualenv for you. Any command you run with `uv run` from the root of a repo will be aware of its environment, you don't even need to activate a virtualenv anymore. This replaces {pyenv, pyenv-virtualenv, virtualenvwrapper,...}.
- uv follows the PEPs for project config (dependencies, optional dependencies, tool configs) in the pyproject.toml so in case uv dies, it's possible to migrate away for the features are defined in the PEPs. Which is not the case for say, poetry.
- uv has a lock file and it's possible to make deps platform specific (Windows, Linux, MacOS, etc). This is in compliance with a PEP but not supported by all tools.
- uv supports custom indexes for packages so you can prefer a certain index, for example your company package index or pytorch's own index (for ML work).
- very fast, makes local dev very seamless and is really helpful in CI/CD where you might just setup and tear down python envs a lot.
Also, the team is responsive on Github so it's easy to get help.