Bottom line: run
python -m pytest, orpy.test-<version>if your alternative Python andpytestare installed with system package manager, or- if your alternative Python has been installed with
pyenv, switch withpyenvto that version and make sure you havepytestinstalled for it. Then you can just runpytest.- since the
pipexecutable is also among the ones being switched, you need to switch to the alternative Python before installingpytestfor it, too.
- since the
As I can see, /usr/bin/pytest (that belongs to the system package manager’s python-pytest package) has a shebang !#/usr/bin/python since it corresponds to the system python’s installation.
pyenv, as its README.md says, does not replace /usr/bin/python – because it indeed should not be replaced to avoid breaking system packages.
Instead, it adds its directory to PATH and inserts a launcher there (called “shim”) which is what gets invoked when you type “python“. As you probably guessed, this hack is ignored by a shebang like the above – as it should.
- Running
python -m pytestwill make whicheverpythonthat launches itself use the package from its installation. - Alternatively,
pytestfor your other Python version may include versioned executables on thePATHnamedpy.test-<version>(e.g.py.test-3orpy.test-3.6) depending on the way you installed it.- If it’s from a system package manager’s package for nonstandard python – like
python36-pytest– this is virtually guaranteed. - I checked that if you install a version with
pip, it only creates an unversioned executable (though you can create a versioned one yourself). Moreover, if you install the same package for a different Python version but with the same--prefix, it will overwrite the existing one’s executable!
- If it’s from a system package manager’s package for nonstandard python – like
pyenv‘s suggested way seems to be to install allpythonversions of interest and packages for them under~/.pyenv/versions.- This is not applicable for the system’s Python but the default
/usr/localcan be used for it. - Once you switch to an alternative Python version, it claims to create shims for all scripts (including
pip!) that are currently installed for that version, so invoking those scripts without a path would run those shims.- So, if a package (and thus its script) is not installed for the alternative version but installed for system version, trying to run its executable would “fall through” to
/usr/localwith just the result you’re seeing now.
- So, if a package (and thus its script) is not installed for the alternative version but installed for system version, trying to run its executable would “fall through” to
- This is not applicable for the system’s Python but the default