deprecate pytest_namespace alltogether

[RonnyPfannschmidt]

with the merge of #2636 pytest itself no longer needs the pytest_namespace hook

the need for preinit is gone as well
so to follow up we should remind people that the hook is deprecated

• print deprecation warnings when hook definitions are found
• changelog
• notes about there not being a replacement
• deprecation roadmap entry

[nicoddemus]

What we need to do, from the top of my head:

1. In pytest, if pytest_namespace returns something other than [] issue the deprecation warning, including the dictionary keys to help users figure out which plugin is using pytest_namespace.
2. Include a note in the CHANGELOG, pointing out to the documentation;
3. Add a .. note: to the docs about the deprecation and when we plan to remove it; also make sure to provide an example about what to replace pytest_namespace with;
4. Add an entry to the Deprecation Roadmap.

[olymk2]

just curious, what the alternative to pytest_namespace ?

I am currently using this, so my functions are registered under pytest.myfunc, the only reference i could find to it being deprecated was in the test code, but nothing about what i should be using in its place ?

[RonnyPfannschmidt]

@olymk2 there will not be a replacement use own modules ^^

[olymk2]

not sure what you mean, currently i have my own plugin which I register a few methods in.

these are registered inside pytest_namespace as local functions and returned in the dictonary.

so are you saying i need to import every plugin I want to use now, and they dont auto register under pytest namespace ?

[RonnyPfannschmidt]

no plugin "auto-registers" under pytest - its just that pytest-namespace will no longer be called

it was never implemented correctly and prevents correcting horrendous bug in config initialization

[olymk2]

how does it auto register then.

if i take my function out of the namespace its not picked up, so there must be some other method of registering the function to pytest does it need a specific prefix in the function name perhaps ?

[RonnyPfannschmidt]

@olymk2 you will have to import from your plugin then instead of using pytest

[olymk2]

ah I see, I may leave that for another day then as that will break any software using this plugin, as you will need to add the import to any project using it.

Also not sure how that works when you use pytest command line to configure the plugin is that likely to still work if its a seperate plugin ?

[RonnyPfannschmidt]

@olymk2 there will be a major aka breaking pytest release to remove the feature
so right now you dont have to fear for your users, and you can prepare for the removal slowly as it will be a long time before the removal is finalized

first we will deprecate it, start to warn about it and work with the authors of public plugins to remove its uses gracefully

[olymk2]

okay thanks, feels like it would be nice to have another way like a hook to keep things under the same namespace.

@pytest_register_method
def myequals()
    return True

import pytest
assert pytest.myequals() is True

for example.

[nicoddemus]

I thought a possible workaround would be to import pytest and manually set your objects as attributes:

def pytest_configure():
    import pytest
    pytest.myequals = myequals

For setuptools-based plugins this should work for most cases, depending on how myequals is meant to be used.

[RonnyPfannschmidt]

@olymk2 one of the main idea is to stop things that are not part of pytest dump random code into its namespace

the other part is, its inherently incompatible with nested test runs and has no sane cleanup

its pretty much a broken way to do things

[olymk2]

okay, good to know @RonnyPfannschmidt I may start down that route then, or fall back to @nicoddemus suggestion if it takes to long I was actually considering some thing like that myself as a workaround.

but I will aim for separating it out into its own import.

[nicoddemus]

With pytest-dev/pluggy#138 this is now much easier right @RonnyPfannschmidt? I think we should do this as soon as we get a new pluggy release.

[RonnyPfannschmidt]

@nicoddemus thats the plan, i did that pluggy r precisely to do the pytest-namespace deprecation

[nicoddemus]

I thought so 😉. @tgoodlet do you have any plans for the next release? Related: pytest-dev/pluggy#140

[indyana]

I never received warnings about this depreciation, so caused some scrambling when 4.1 upgrade occurred. I had used the hook in my core conf_test file to store some global test session values for use outside tests.

[nicoddemus]

Hi @indyana

I never received warnings about this depreciation, so caused some scrambling when 4.1

Strange, we have been issuing a warning since 3.7.0. Did you upgrade from 3.6 to 4.1 directly?

[slarse]

@nicoddemus I used pytest_namespace to store some global constants and functions for my test suite (which I now realize was probably pretty dirty), and did not receive any warnings when running 3.9.1. Then my builds failed on upgrading to 4.1.1. Could it possibly be that pytest_namespace was checked before conftest.py was loaded, and thus the warning wouldn't trigger for those of us who used it that way?

PS: Caused super minor issues for me, just thought the info could be useful!

[nicoddemus]

Hi @slarse,

Sorry to hear that. AFAIK it should emit the warning at the point that pytest calls the hook, so it wouldn't matter where it was defined, if it was working (IOW, if the hook was actually being called).

But now I'm wondering, because we didn't seem to have a test for that. @RonnyPfannschmidt do you remember if we tested this warning at some point?

[indyana]

No, I was incrementally upgrading all along. I went back and locked the test requirements down to 4.0.2 for a few weeks until I could get around to fixing by using a module import instead of pytest_namespace; there still were not any warnings in 4.0.2.

[nicoddemus]

@indyana thanks.

Weird, it was deprecated in #3735, so it should have been emitting warnings since then when a pytest_namespace hook was encountered. 🤔

[nicoddemus]

Btw we are sorry for the trouble, we really tried to make the transition as smooth as possible, but it seems we had a few hiccups along the way. 😞

[indyana]

Dirt simple example of this behavior, in case it helps you in the future. It wasn't a huge deal, more wanted to make you aware that the way this alert was done wasn't visible to at least a few users out there. :)

(venv) C:\<blah>\deprecated_check>pytest
============================= test session starts =============================
platform win32 -- Python 3.7.1, pytest-4.0.2, py-1.7.0, pluggy-0.8.1
rootdir: C:\<blah>\deprecated_check, inifile:
collected 1 item

test_example.py .                                                        [100%]

========================== 1 passed in 0.03 seconds ===========================

deprecated_check.zip

[slarse]

@nicoddemus I feel the need to mention that my problems were minuscule, solved by some copy paste and sed magic, and that you guys are doing a fantastic job with this project. Diagnosing the problem is very easy because pluggy simply spits out an error message that ends with:

INTERNALERROR> pluggy.manager.PluginValidationError: unknown hook 'pytest_namespace' in [...]

[RonnyPfannschmidt]

@nicoddemus i wonder if we have a few pathological case in the warning capturing/recording where the normal output is already silenced, but the tracking is not yet correctly in place

[nicoddemus]

@RonnyPfannschmidt indeed, unfortunately due to how config and plugins are initialized we might be missing some early warnings.