pypyr.steps.python

Get the full path of the executable binary of the Python interpreter running the current pypyr session.

The step writes the absolute path as a string to the python key in context.

This means that wherever you would’ve invoked python or python3 as a subprocess, you can instead use {python}. This will replace the {python} token with the absolute path of the Python executable that is currently running pypyr.

This step doesn’t take any inputs, so you can always run it as a simple step.

steps:
  - pypyr.steps.python

  - name: pypyr.steps.cmd
    comment: build wheel + sdist 
    description: --> build wheel + sdist to dist/
    in:
      cmd: '"{python}" setup.py bdist_wheel sdist'  

Note the double quote around "{python}". This is to make sure that if there are any spaces in the file-path given by {python} it still parses correctly when passed as a cmd to open as a sub-process.

But why? Especially on Windows, if you just invoke Python as a sub-process from pypyr like this:

steps:
  name: pypyr.steps.cmd
  in:
    cmd: python -m stuff.do

You might run into trouble because python will resolve to the system Python interpreter, rather than the currently active virtual environment. Therefore any dependencies you’ve installed in the virtual environment WON’T necessarily be available in the system site packages.

This is unlikely to be the behavior that you want if you’re running inside an active venv.

To avoid this issue, use pypyr.steps.python and compose your command with "{python}" rather than python:

steps:
  - pypyr.steps.python
  - name: pypyr.steps.cmd
    comment: will run in currently active python env
    in:
      cmd: '"{python}" -m stuff.do'  

See the Python docs for Popen for details.