pytest-djangoapp
pytest-djangoapp copied to clipboard
Defining 'pytest_plugins' in a non-top-level conftest is no longer supported
c.f. https://github.com/idlesign/django-siteprefs/issues/18#issuecomment-634695472
Running tests on openSUSE Tumbleweed build bots (platform linux -- Python 3.8.3, pytest-5.3.5, py-1.8.1, pluggy-0.13.1 - cant change this)
[ 48s] + PYTHONPATH=:/home/abuild/rpmbuild/BUILDROOT/python-pytest-djangoapp-0.14.0-3.1.x86_64/usr/lib/python3.8/site-packages
[ 48s] + PYTHONDONTWRITEBYTECODE=1
[ 48s] + py.test-3.8 --ignore=_build.python2 --ignore=_build.python3 --ignore=_build.pypy3 -v
[ 49s] ============================= test session starts ==============================
[ 49s] platform linux -- Python 3.8.3, pytest-5.3.5, py-1.8.1, pluggy-0.13.1 -- /usr/bin/python3
[ 49s] cachedir: .pytest_cache
[ 49s] rootdir: /home/abuild/rpmbuild/BUILD/pytest-djangoapp-0.14.0
[ 49s] collecting ... collected 0 items / 1 error
[ 49s]
[ 49s] ==================================== ERRORS ====================================
[ 49s] ________________________ ERROR collecting test session _________________________
[ 49s] Defining 'pytest_plugins' in a non-top-level conftest is no longer supported:
[ 49s] It affects the entire test suite instead of just below the conftest as expected.
[ 49s] /home/abuild/rpmbuild/BUILD/pytest-djangoapp-0.14.0/pytest_djangoapp/tests/conftest.py
[ 49s] Please move it to a top level conftest file at the rootdir:
[ 49s] None
[ 49s] For more information, visit:
[ 49s] https://docs.pytest.org/en/latest/deprecations.html#pytest-plugins-in-non-top-level-conftest-files
[ 49s] !!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
maybe just a tiny problem with layout of the test wrt newish pytest.
Added this to my .spec and all tests pass.
mv ./pytest_djangoapp/tests/conftest.py .
However notably https://github.com/idlesign/pytest-djangoapp#how-to-use says to put the conftest.py under the app tests directory.
The tests are meant to be run with python setup.py test.
Or you may want to change current working directory to pytest_djangoapp (containing tests directory) before running tests.
pytest (in recent versions) expects tests in the root of a package, whereas classic Django tests for app location is inside app directory.
That is to say our conftest IS top-level conftest, but pytest seems to be not clever enough to spot it.
Ya, perhaps document this in the README?
Yes, this may be a good idea depending on the exact needs.
Do you mean you want to see some instructions on how to run the testsuite not in CI, manually?
Then it probably may be placed in CONTRIBUTING.
Or do you want to see some other instructions?
I have my (non-paid/unaffiliated) distro packaging hat on.
I find I need one of your django packages, and create a spec for it. I then find that to test your django app in my builds , I first need to first create a distro package for pytest-djangoapp . Assuming I have made it that far, if it fails to build, I am likely to give up on testing and ship a django app package that isnt tested. This is exactly what I did, but 'planning' to get back to the pytest plugin.
I tried 'setup.py test' and I tried 'pytest', and that was the end for me. I know the error, I know the usual fix, but time is precious, I got a kid who wants to play lego, etc, etc.
So, ideally the test harness for your pytest plugin should 'just work'. I'll revisit why setup.py test didnt work. Despite setup.py test being deprecated, it is what distro packagers usually use.
Just invoking pytest in the top level of this project also should work. If it doesnt, the distro packager needs some really visible instructions on how to get it working.
So I have a package for pytest-djangoapp now, and using setup.py test on my siteprefs build, after installing pytest-runner because the setup.py tells me it is mandatory. It fails; log excerpt below. Full log at https://build.opensuse.org/package/show/home:jayvdb:django/python-django-siteprefs but you probably need to create account / log in to see everything there.
In my experience, you wont get much help from the pytest-runner maintainers, so you would need to create your own helper which changes directory , if that is necessary to get pytest working correctly.
[ 45s] + /usr/bin/python3 setup.py test
[ 45s] running pytest
[ 45s] running egg_info
[ 45s] writing django_siteprefs.egg-info/PKG-INFO
[ 45s] writing dependency_links to django_siteprefs.egg-info/dependency_links.txt
[ 45s] writing requirements to django_siteprefs.egg-info/requires.txt
[ 45s] writing top-level names to django_siteprefs.egg-info/top_level.txt
[ 45s] reading manifest file 'django_siteprefs.egg-info/SOURCES.txt'
[ 45s] reading manifest template 'MANIFEST.in'
[ 45s] warning: no files found matching '*.py' under directory 'siteprefs/south_migrations'
[ 45s] writing manifest file 'django_siteprefs.egg-info/SOURCES.txt'
[ 45s] running build_ext
[ 45s] ============================= test session starts ==============================
[ 45s] platform linux -- Python 3.8.3, pytest-5.3.5, py-1.8.1, pluggy-0.13.1
[ 45s] rootdir: /home/abuild/rpmbuild/BUILD/django-siteprefs-1.2.0
[ 45s] collected 0 items / 1 error
[ 45s]
[ 45s] ==================================== ERRORS ====================================
[ 45s] ________________________ ERROR collecting test session _________________________
[ 45s] Defining 'pytest_plugins' in a non-top-level conftest is no longer supported:
[ 45s] It affects the entire test suite instead of just below the conftest as expected.
[ 45s] /home/abuild/rpmbuild/BUILD/django-siteprefs-1.2.0/siteprefs/tests/conftest.py
[ 45s] Please move it to a top level conftest file at the rootdir:
[ 45s] None
[ 45s] For more information, visit:
[ 45s] https://docs.pytest.org/en/latest/deprecations.html#pytest-plugins-in-non-top-level-conftest-files
[ 45s] !!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
[ 45s] =============================== 1 error in 0.16s ===============================
So, ideally the test harness for your pytest plugin should 'just work'. I'll revisit why setup.py test didnt work.
Sure. It does from what I see in Travis and locally in TOX when classic python packaging (non distro-specific) + virtualenv approach is used. Distro-packaging from my experience may require a lot of effort.
Despite setup.py test being deprecated, it is what distro packagers usually use.
Al last. Thank you for the info. Missed that from last October. Seems will need to switch to something else (e.g. tox).
So I have a package for pytest-djangoapp now, and using setup.py test on my siteprefs build, after installing pytest-runner because the setup.py tells me it is mandatory. It fails; log excerpt below.
I've probabaly lost you there. You've made rpm's for djangoapp and siteprefs, installed both, and then trying to run siteprefs testsuite through setup.py? If so how setup.py appeared in your rpm, what's it's purpose in rpm? Do you want to test your packaging is fine using provided tests aimed to test apps behaviour?
I've probabaly lost you there. You've made rpm's for djangoapp and siteprefs
Sort of. The rpmbuild for siteprefs fails because it has a %check phase which invokes python3 setup.py test as mentioned in the log above.
I believe you can at least see the .spec without an account, if it interests you. https://build.opensuse.org/package/view_file/home:jayvdb:django/python-django-siteprefs/python-django-siteprefs.spec?expand=1
Do you want to test your packaging is fine using provided tests aimed to test apps behaviour?
Yes, I want to ensure that siteprefs continues to be packaged correctly for years to come. Over those years, siteprefs will have new releases, versions of the dependencies provided by the OS will change, and packaging processes will change, and people will do automated .spec rewrites and occasionally those introduce failures which wont be caught unless there are tests.
e.g. packaging tests have helped enormously when the rolling Tumbleweed distro has moved to Django 2.2 and 3.0 quite soon after the core part of the Django ecosystem had upgraded. There is a long tail of other Django packages needing manual patches applied, and these packaging tests are the way to determine which packages are in need of some attention in order to be compatible.