[j4mie]

It's worth noting that uv also supports a workflow that directly replaces pyenv, virtualenv and pip without mandating a change to a lockfile/pyproject.toml approach.

uv python pin <version> will create a .python-version file in the current directory.

uv virtualenv will download the version of Python specified in your .python-version file (like pyenv install) and create a virtualenv in the current directory called .venv using that version of Python (like pyenv exec python -m venv .venv)

uv pip install -r requirements.txt will behave the same as .venv/bin/pip install -r requirements.txt.

uv run <command> will run the command in the virtualenv and will also expose any env vars specified in a .env file (although be careful of precedence issues: https://github.com/astral-sh/uv/issues/9465)

[slau]

uv and its flexibility is an a absolute marvel. Where pip took 10 minutes, uv can handle it in 20-30s.

[ljm]

It’s an absolute godsend. I thought poetry was a nice improvement but it had its flaws as well (constant merge conflicts in the lock file in particular).

Uv works more or less the same as I’m used to with other tooling in Ruby, JS, Rust, etc.

[robertlagrant]

How does uv avoid merge conflicts in lock files? I need a reason to switch.

[ljm]

I never got a chance to see the difference there because I moved on shortly after.

It was just that almost constant conflicts with poetry (and the errors about the project being out of sync) with a team developing in parallel were painful enough for me to suggest we try uv instead.

It seemed uniformly better with a simpler docker setup too (although I liked how pants would created executable bundles and you could just ship those).

[robertlagrant]

Fair enough! I'm a bit surprised that anyone could get regular out of sync errors unless a team member were constantly updating dependencies every commit. But then if they did that with uv I'd imagine they'd have the same issue. Unless uv does something extra smart and creates you a new environment for every git branch.

[smeeth]

+1, this is the exact reason I started using uv. Extremely convenient.

For some reason uv pip has been very slow, however. Unsure why, might be my org doing weird network stuff.

[greenavocado]

Or very difficult package spec

[politelemon]

Doesn't it store the python version in the pyproject.toml though, is the python version file needed?

[JimDabell]

It’s not:

> uv will respect Python requirements defined in requires-python in the pyproject.toml file during project command invocations. The first Python version that is compatible with the requirement will be used, unless a version is otherwise requested, e.g., via a .python-version file or the --python flag.

— https://docs.astral.sh/uv/concepts/python-versions/#project-...

[politelemon]

cheers