Running with --no-venv causes session.install to use unexpected interpreter

[rhoban13]

Describe the bug
Running with --no-venv causes session.install to be invoked with the python executable found on PATH, not the one running nox.

How to reproduce
Running in an environment where the executables python and python3.8 are distinct:

$ which python python3.8
/usr/bin/python
/usr/bin/python3.8

My noxfile.py just installs pytest. Running we obtain:

$ python3.8 -m nox --no-venv
nox > Running session validate
nox > python -m pip install pytest
nox > Command python -m pip install failed with exit code 1:
/usr/bin/python: No module named pip
nox > Session validate failed.

Ignore the "No module named pip", the point being it's invoking /usr/bin/python, not /usr/bin/python3.8.

Expected behavior
Documentation on forcing-sessions-backend suggests this should run "on the current python interpreter (the one running nox)".

Possible fix
I suspect a fix could be applied in Session.install here to use sys.executable instead of the string `"python". I'm not certain what conditions we'd need to check beforhand (how to verify we aren't running in a venv).

[cjolowicz]

Thanks for reporting this!

I suspect a fix could be applied in Session.install here to use sys.executable instead of the string `"python". I'm not certain what conditions we'd need to check beforhand (how to verify we aren't running in a venv).

That should work. You can check if self._runner.venv is an instance of PassthroughEnv, as that's the one that implements the --no-venv feature.

[theacodes]

I feel like invoking "install" without a virtual environment should be an error, since all sorts of unexpected behavior can happen. If someone wants to actually install something in the global python interpreter, they can run pip install via session.run.

…

On Fri, Nov 12, 2021, 11:41 PM Claudio Jolowicz ***@***.***> wrote: Thanks for reporting this! I suspect a fix could be applied in Session.install here to use sys.executable instead of the string `"python". I'm not certain what conditions we'd need to check beforhand (how to verify we aren't running in a venv). That should work. You can check if self._runner.venv is an instance of PassthroughEnv, as that's the one that implements the --no-venv feature. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#503 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5I46NLCZWEKFTZUQYLUTULXT7HANCNFSM5H534MMQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[rhoban13]

I feel like invoking "install" without a virtual environment should be an error, since all sorts of unexpected behavior can happen. If someone wants to actually install something in the global python interpreter, they can run pip install via session.run.

I agree you typically shouldn't install things into the global python interpreter, however that doesn't seem like it should be nox's responsibility to validate. This is basically why pip --require-virtualenv exists, I tend to export PIP_REQUIRE_VIRTUALENV in most setups to check this.

[theacodes]

Okay, sure, but I still don't think Nox should have a footgun like this that's only turned off if the user knows some arcane pip stuff. We could raise a helpful error when trying to use install without a virtualenv, something like:

Session {name} does not have a virtual environment, so you can't use

session.install() since it would modify the global Python environment. If you're really sure that is what you want to do, use session.run("pip", "install", ...) instead.

…

On Sun, Nov 14, 2021 at 12:20 PM Ryan Hoban ***@***.***> wrote: I feel like invoking "install" without a virtual environment should be an error, since all sorts of unexpected behavior can happen. If someone wants to actually install something in the global python interpreter, they can run pip install via session.run. I agree you typically shouldn't install things into the global python interpreter, however that doesn't seem like it should be nox's responsibility to validate. This is basically why pip --require-virtualenv <https://pip.pypa.io/en/latest/cli/pip/#cmdoption-require-virtualenv> exists, I tend to export PIP_REQUIRE_VIRTUALENV in most setups to check this. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#503 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5I46VKJYYLJ4JIRBADUDUL7VXNANCNFSM5H534MMQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[DiddiLeija]

Yup, an error message (or even just a warning) would be better than doing pip variable manipulations. If you want, in the next week I can post a PR to do this. We only need to sketch how the message should look like ;)

[cjolowicz]

I agree that session.install without a venv backend is dangerous, and it would be better to raise a helpful error here. However, this is a breaking change, and there are projects out there that rely on the current behavior (e.g. here and here). This behavior was explicitly allowed in #316, see #318 and #301 for background. Should we go through a deprecation phase then?

[rhoban13]

#301 is exactly the use case I'm interested in.