Skip to content

pytester: set PYTEST_DISABLE_PLUGIN_AUTOLOAD=1#6166

Closed
blueyed wants to merge 2 commits intopytest-dev:featuresfrom
blueyed:pytester-PYTEST_DISABLE_PLUGIN_AUTOLOAD=1
Closed

pytester: set PYTEST_DISABLE_PLUGIN_AUTOLOAD=1#6166
blueyed wants to merge 2 commits intopytest-dev:featuresfrom
blueyed:pytester-PYTEST_DISABLE_PLUGIN_AUTOLOAD=1

Conversation

@blueyed
Copy link
Contributor

@blueyed blueyed commented Nov 9, 2019

Via blueyed#80

(cherry picked from commit e5fff3f)

@blueyed blueyed changed the title pytester: set PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 (#80) pytester: set PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 Nov 9, 2019
@blueyed
Copy link
Contributor Author

blueyed commented Nov 9, 2019

Needs blueyed#78 (and some more likely).
Let me know if you are interested, otherwise I will close it in the next days.

The use case is to not have outer plugins interfere with tests.

@nicoddemus
Copy link
Member

Thanks.

This will break runninh with xdist and such, no? TBH not sure this is worthwhile, we should delegate having "clean" environments to tox runs. I don't think we need to guard against polluted environments when running outside tox. I fear there are many more situations where an unclean environment might interfere with tests, and would be very hard to enforce them all in testdir.

Closing then, but thanks anyway. 👍

@nicoddemus nicoddemus closed this Nov 12, 2019
@blueyed blueyed deleted the pytester-PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 branch November 12, 2019 17:42
@blueyed
Copy link
Contributor Author

blueyed commented Nov 12, 2019

Yes, IIRC we had that before, and that's why I also started working on an option (moved to blueyed#71 for now).
IIRC I suggested using the env for what that option does (i.e. 1 means the same as empty, i.e. load none), and you can specify a list there then maybe. Having both an option and env for the same purpose might be confusing, and it seems like handling it via an option on complicates things.

tox

Yeah, but using it by itself is slower, and the idea here is that you can actually use other plugins without pytests owns tests failing (e.g. pytest-randomly etc).

@nicoddemus
Copy link
Member

Yeah, but using it by itself is slower, and the idea here is that you can actually use other plugins with pytests owns tests failing (e.g. pytest-randomly etc).

That's fine, but I wouldn't like to go out of our way to support that; I know the PR here is simple enough, but I wouldn't like to guarantee support for that as this seems like a slippery slope to me.

@blueyed
Copy link
Contributor Author

blueyed commented Nov 12, 2019

Hmm, not sure I understand?
(I've edited s/with/without)
Do you mean not guaranteeing support to use other plugins with pytests own tests?
Yeah, that's pretty much the case already then.. :)

@nicoddemus
Copy link
Member

Do you mean not guaranteeing support to use other plugins with pytests own tests?
Yeah, that's pretty much the case already then.. :)

Exactly.

@blueyed
Copy link
Contributor Author

blueyed commented Nov 22, 2019

@nicoddemus
JFI/for reference: I've moved it to testing/conftest.py myself for pytest's own tests only then (blueyed#134).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants