Pytest: Way to isolate tests from existing environment variables?

[simonvanderveldt]

It could be I've missed something but I've done quiet a bit of searching and it seems there's no out of the box/default way of isolating tests from the environment variables from the calling environment.
Is this something that could be added or was this a conscious design decision?

As a workaround I currently do this in conftest.py, which works, though I'm not sure how much I'm abusing the system by doing this :P

def pytest_addhooks(pluginmanager):
    os.environ = {}

And as an extension of this it would be nice if there would be a way to have this isolation and allow one to globally override/set environment variables before discovery/importing happens, to allow easy testing of modules that make use of environment variables at module level. This sounds similar to https://github.com/pytest-dev/pytest/issues/3597
I'd currently do that using:

def pytest_addhooks(pluginmanager):
    os.environ = {"FOO": "bar"}

I guess a more specific hook one could add to conftests.py that runs before module discovery/import might be one way to enable something like this.

[blueyed]

JFI: typically CI systems ensure this by design, and tox can also be used for this (where you have to explicitly use passenv).

[nicoddemus]

IMHO environment isolation is done better by an external tool than adding this to pytest itself, because it is hard to do it correctly from within pytest.

[blueyed]

Agreeing with @nicoddemus, and closing.

[simonvanderveldt]

Hmm, seems rather odd to depend on external tools for basic testing functionality, right?

IMHO environment isolation is done better by an external tool than adding this to pytest itself, because it is hard to do it correctly from within pytest.

From this I assume it's more complex than just setting os.environ to None or {}?
What's so difficult about it? What we do now seems to be working just fine, but there might still be a technical reason I'm not aware of that it's a bad idea.

[RonnyPfannschmidt]

replacing os.environ is pretty much fundamentally broken and you are lucky if things didn't blow up ^^

[simonvanderveldt]

@RonnyPfannschmidt Do you have any more info on what exactly is fundamentally broken?

[RonnyPfannschmidt]

@simonvanderveldt os.environ is a instance of a private mapping class that maps to the underlying c functions that set/get environment variables

shadowing it with random python data structures just hides away access to the actual data that will still affect subprocesses and c libraries and in addition it breaks expectations for quite a few things out there

[simonvanderveldt]

@RonnyPfannschmidt Thanks for the info. So far we're doing pure Python only so I guess we should be fine. Will keep it in mind though for possible future situations :)

[RonnyPfannschmidt]

@simonvanderveldt i strongly suggest to limit this hack as intensely as possible - its a really good starting point for unexpected failures