You do not need a damn good reason for this. Just try it out on a simple hello world. Then try it out on a project already using poetry for eg.
uv init
uv sync
and you're done
I'd say if you do not run into the pitfalls of a large python codebase with hundreds of dependencies, you'll not get the bigger argument people are talking about.
I do usually include instructions in our READMEs to do a `uv sync` as install command, in order to separate error causes, and also to allow for bootstrapping the venv so that it's available for IDEs.
You can still `source .venv/bin/activate(.fish)` and skip the uv run bit. I have Fish shell configured to automatically activate a .venv if it finds one in a directory I switch to.
I keep going back and forth on ‘uv run’. I like being explicit with the tooling, but it feels like extra unneeded verbosity when you could just interact with the venv directly. Especially since I ported a bunch of scripts from ‘poetry run’
