Tox: PYTHONPATH warning should have more context and not be displayed in red

[cs01]

I am just getting started with tox, and got a big red warning when running tox --notest. This was surprising, yet as far as I could tell nothing was wrong.

This is what I saw in red:

WARNING: Discarding $PYTHONPATH from environment, to override specify PYTHONPATH in 'passenv' in your configuration.

I propose it be changed from WARNING: to Note: and that it be changed from red to white.

[gaborbernat]

This is on purpose and we have no plans to change it. Care to detail why you think we should?

[cs01]

Here was a breakdown of my first experience with tox

• Run tox as described in a README
• Get a large red message
• Mentally go into debug mode because something broke
• Read the message and find out it's a warning (and nothing actually broke)
• The warning means nothing to me because I don't care about PYTHONPATH, nor do I even really understand why I'd want to do that in the first place since I want tox to manage everything for me. I like tox to be hermetic (in my limited use so far).
• Now every time I run tox, I am getting this same message that I don't care about that doesn't apply to me
• Now I am conditioned to ignore big red messages from tox

I suggested changing to white text and a note because it seems like the warning is too severe and in-your-face. Also, I have never seen a cli warning printed in red. Yellow, yes, but not red. I don't even set $PYTHONPATH in my shell; the only reason tox was mentioning it is because I was in an activated virtual environment which had set it.

I suggest giving more context in the warning, and giving more steps on how to fix or silence it. For example (not sure if I have the details right):

The environment variable PYTHONPATH is set in your shell. When tox calls into its virtual envrionments, the PYTHONPATH environment variable will not be present unless passenv is found in your tox configuration. To ignore this and other warnings, pass the --quiet flag.

[gaborbernat]

virtualenv activation does not set PYTHONPATH (https://github.com/pypa/virtualenv/blob/master/virtualenv_embedded/activate.sh#L4). You must have set it somehow manually. The red message is there to warn you one should not do this. It could be yellow overall though.

GitHub

pypa/virtualenv

Virtual Python Environment builder. Contribute to pypa/virtualenv development by creating an account on GitHub.

[gaborbernat]

I think it's alright as it is for now, unless more people want to change it

[BeyondEvil]

virtualenv activation does not set PYTHONPATH (https://github.com/pypa/virtualenv/blob/master/virtualenv_embedded/activate.sh#L4). You must have set it somehow manually. The red message is there to warn you one should not do this. It could be yellow overall though.

GitHubpypa/virtualenvVirtual Python Environment builder. Contribute to pypa/virtualenv development by creating an account on GitHub.

I'm reading this as "One should not set PYTHONPATH". Am I reading that right?

If so, why not? That's the only way I've found to have my python3 projects run without littering them with empty __init__.py files.

LOVE tox tho, use it _everywhere_ 😊

FWIW I use pipenv

[Feuermurmel]

My expectation was that a Python instance running inside of Tox would not be influenced by $PYTHONPATH. I was surprised when I saw this message the first time and it took me some time to find out that there wasn't anything wrong. My gut feeling was that the message was trying to tell me that the variable _does_ interfere with Tox for some reason (e.g. a bug which can't be fixed because of backwards compatibility).

What is the intended way of running tox in an environment where $PYTHONPATH is set? I'm using that variable to point to a sitecustomize.py I would like to be used even inside of manually created virtualenvs. But of course I don't want it to be used when Python is running inside of Tox.

[SethMMorton]

Is there a way to tell tox "yes, I have PYTHONPATH set, and yes, I acknowledge that tox is dropping it, so don't show me this warning"? In otherwords, some setting that will still drop PYTHONPATH but not raise a big hairy deal about it?

[gaborbernat]

No there isn't.

[jugmac00]

The environment variable PYTHONPATH is set in your shell. When tox calls into its virtual envrionments, the PYTHONPATH environment variable will not be present unless passenv is found in your tox configuration. To ignore this and other warnings, pass the --quiet flag.

I like this message a lot - just saying :-)

Came here because I did not understand the current error message... ¯_(ツ)_/¯

[cs01]

After posting this originally I tried nox and have not looked back. It’s like tox but you define tasks with python instead of a DSL. I have found its ui very user friendly and intuitive too. https://github.com/theacodes/nox

[gaborbernat]

I'd urge caution for people jumping into the imperative bandwagon. Writing python is great if you're an advanced user, but having dynamic code run means it's hard to validate that you do not shot yourself in the foot with it. I hope we learned these lessons from setuptools, to quote @pganssle

Ideally the default option would be a declarative build configuration that works well for the 99% case, with an option to fall back to an imperative system when you really need the flexibility. At this point, it's feasible for us to move to a world where it's considered a code smell if you find you need to reach for the imperative build options.
The biggest problem with setup.py is that most people use it declaratively, and when they use it imperatively, they tend to introduce bugs into the build system. One example of this: if you have a Python 2.7-only dependency you may be tempted to specify it conditionally with sys.version in your setup.py, but sys.version only refers to the interpreter that executed the build; instead, you should be using the declarative environment markers for your install requirements..