[supakeen]

The activation of the virtualenv is unnecessary (one can execute pip/python directly from it), and the configuring of your local pyenv interpreter is also unnecessary, it can create a virtual environment with one directly:

  pyenv virtualenv python3.12 .venv
  .venv/bin/python -m pip install pandas
  .venv/bin/python

Not quite one command, but a bit more streamlined; I guess.

[BeeOnRope]

Note that in general calling the venv python directly vs activating the venv are not equivalent.

E.g. if the thing you run invokes python itself, it will use the system python, not the venv one in the first case.

[meitham]

Surely if you want to invoke python you call sys.executable otherwise if your subprocess doesn’t inherit PATH nothing will work with uv or without uv

[BeeOnRope]

I don't think that's "sure" at all. For one thing, only Python code directly calling Python has that option in the first place, often there is another layer of indirection, e.g., Python code which executes a shell script, which itself invokes Python, etc.

IME it is common to see a process tree with multiple invocations of Python in a ancestor relationship with other processes in between.

[zahlman]

In rare cases, programs might also care about the VIRTUAL_ENV environment variable set by the activate script, and activation may also temporarily clear out any existing PYTHONHOME (a rarely used override for the location of the standard library). But yes, in general you can just run the executable directly.

[astronautas]

Indeed, you're right ;).