Turns out you can just do things. The astral tooling is by far the best thing that has happened to Python in years and it makes me very happy.
replies(2):
E.g.
uv init --script foo.py
uv add --script foo.py httpx
cat foo.py
...
dependencies = ['httpx']
...
uv run foo.py
# creates a virtual env, reads foo.py to see httpx is a dependency, installs in the ephemeral venv then runs the script
First, you can move that script to a different machine and do `uv run {script}`, no need to recreate a venv or provide install instructions (I believe uv will now even grab an appropriate version of Python if you don't have it?). This comes from PEP 723, and multiple tools support doing this, such as hatch.
Second, when you "add" a requirement instead of "install" a requirement it manages that with the knowledge of all requirements that were added before. For example, if I `pip install foo` and then `pip install bar` pip does not consider foo or it's dependencies as required when installing bar, so it's possible that you can break `foo` by installing completely incompatible dependencies. But when you "add foo" and then "add bar" from uv (and other tools that are declarative, like Poetry) your environment gets updated to take everything into account.
If managing Python dependencies is second nature to you then these might seem like extra concepts to keep in your head, but lots of people do find these useful because they find they can think less about Python dependencies.
Before (analogous to go mod init):
python -m venv venv
source venv/bin/activate
python -m pip install -U pip
pip install httpx
pip freeze > requirements.txt
nvim foo.py
# find a way to share foo.py and requirements.txt
python -m venv venv
source venv/bin/activate
python -m pip install -U pip
pip install -r requirements.txt
python foo.py
uv run foo.py
./my-go-binary