A uv run subcommand

[konstin]

In the initial implementation, the puffin run subcommand looks for a venv in .venv in the current or any parent directory, activates it by setting VIRTUAL_ENV and PATH and then replaces itself with the python interpreter with the trailing args (on unix, it might be faster to not spawn a new process but load libpython and run Py_Main).

In further steps we can extend this to read pyproject.toml, create a venv if none exists, install all (missing) dependencies and run. This enables a "git clone and puffin run" workflow where the user does not need to manually handle venvs and dependency installation anymore. puffin run could replace python as batteries-included entrypoint for running python code.

[zanieb]

xref #1173

[henryiii]

This would support PEP 721? One issue with pipx run is it prioritizes classic PyPI apps, so pipx run file.py will look for a file-py on PyPI. So uv run file.py could run a local file, wile uv pipx run could be the PyPI one.

[konstin]

Good question! I'm wondering how to handle conflicts. If a file contains a PEP 723 comment and exists in a uv workspace (with a pyproject.toml with uv configuration), should uv run use the inline metadata or the workspace metadata?

[henryiii]

I believe the inline metadata should override the more general config. It’s the same way I’d hope Ruff support for PEP 723 would work, it’s a way to put per file config in the files. Like the matching feature in Rust (that partially inspired the PEP).

[pfmoore]

I agree that PEP 723 metadata should take precedence. An obvious use case I would have for a feature like this would be to write small "workflow support" scripts in my project directory. These would have their own dependencies, and could very easily not share any dependencies with the project itself (imagine, for example, a make_docs.py script that depended on Sphinx). Such scripts would be a lightweight alternative to a tool like nox.

[zanieb]

See #3074 for the initial implementation of this.

#3096 tracks PEP 723 support.