6.2.4: pytest is failing when setuptools produces DSO module #8731
Comments
|
I can't reproduce - can you please try to reproduce (and ideally also provide reproduction steps) based on a clean virtualenv? |
|
The build command has a inplace option to manage this, same goes for editable installs IMHO no pytest issue |
|
I think that this pytest issue may shares some root cause with failing setuptools AFAIK pytest is reading setup.cfg in which (I suppose) should be some paths to just build resources. In other words in this case it may not be pytest per se issue but more setuptools. |
In this case it is not about virtual env. It is about fact that pytest is not able to locate where are DSO modules. |
Basing on IMO similar case with setuptools |
|
The general suggestion is that if you want to to test either install, build inplace or do a editableinstall Thereis no pytest to setuptools integration a spart of pytest |
That is OK. May I ask how it should be done? |
|
Another observation. %build
%py3_build
%install
%py3_install
%check
%pytestAll is executet in order: forst %build, %insytall and than %check. [tkloczko@barrel SPECS]$ rpm -E %pytest
[.not relevant part.]
PATH="/home/tkloczko/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64/usr/bin:$PATH" \
PYTHONPATH="${PYTHONPATH:-/home/tkloczko/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64/usr/lib/python3.8/site-packages}" \
\
/usr/bin/python3 -Bm pytest -radesptite fact that I'm setting up $PYTHONPATH to the path where all files with DSOs are available pytest is not able to find DSOI modules: + PATH=/home/tkloczko/rpmbuild/BUILDROOT/python-yarl-1.6.3-5.fc35.x86_64/usr/bin:/usr/bin:/usr/sbin:/usr/local/sbin
+ PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-yarl-1.6.3-5.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-yarl-1.6.3-5.fc35.x86_64/usr/lib/python3.8/site-packages
+ /usr/bin/python3 -Bm pytest -ra -q
=========================================================================== test session starts ============================================================================
platform linux -- Python 3.8.9, pytest-6.2.4, py-1.10.0, pluggy-0.13.1
rootdir: /home/tkloczko/rpmbuild/BUILD/yarl-1.6.3, configfile: setup.cfg, testpaths: tests/
plugins: forked-1.3.0, shutil-1.7.0, virtualenv-1.7.0, expect-1.1.0, httpbin-1.0.0, xdist-2.2.1, flake8-1.0.7, timeout-1.4.2, betamax-0.8.1, freezegun-0.4.2, cases-3.4.6, case-1.5.3, isort-1.3.0, aspectlib-1.5.2, asyncio-0.15.1, toolbox-0.5, xprocess-0.17.1, aiohttp-0.3.0, checkdocs-2.7.0, mock-3.6.1, rerunfailures-9.1.1, requests-mock-1.9.3, Faker-8.4.0, cov-2.12.1, pyfakefs-4.5.0, hypothesis-6.13.14
collected 496 items / 1 error / 495 selected
Coverage.py warning: No data was collected. (no-data-collected)
================================================================================== ERRORS ==================================================================================
__________________________________________________________________ ERROR collecting tests/test_quoting.py __________________________________________________________________
ImportError while importing test module '/home/tkloczko/rpmbuild/BUILD/yarl-1.6.3/tests/test_quoting.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib64/python3.8/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/test_quoting.py:9: in <module>
from yarl._quoting_c import _Quoter as _CQuoter, _Unquoter as _CUnquoter
E ModuleNotFoundError: No module named 'yarl._quoting_c'[tkloczko@barrel SPECS]$ ls -lR /home/tkloczko/rpmbuild/BUILDROOT/python-yarl-1.6.3-5.fc35.x86_64/usr/lib64/python3.8/site-packages
/home/tkloczko/rpmbuild/BUILDROOT/python-yarl-1.6.3-5.fc35.x86_64/usr/lib64/python3.8/site-packages:
total 0
drwxr-xr-x 1 tkloczko tkloczko 310 Jun 7 17:55 yarl
drwxr-xr-x 1 tkloczko tkloczko 128 Jun 7 17:55 yarl-1.6.3-py3.8.egg-info
/home/tkloczko/rpmbuild/BUILDROOT/python-yarl-1.6.3-5.fc35.x86_64/usr/lib64/python3.8/site-packages/yarl:
total 612
-rw-r--r-- 1 tkloczko tkloczko 154 Nov 14 2020 __init__.py
-rw-r--r-- 1 tkloczko tkloczko 3702 Nov 14 2020 __init__.pyi
drwxr-xr-x 1 tkloczko tkloczko 642 Jun 7 17:55 __pycache__
-rw-r--r-- 1 tkloczko tkloczko 13 Nov 14 2020 py.typed
-rw-r--r-- 1 tkloczko tkloczko 454357 Jun 7 17:54 _quoting_c.c
-rwxr-xr-x 1 tkloczko tkloczko 94016 Jun 7 17:55 _quoting_c.cpython-38-x86_64-linux-gnu.so
-rw-r--r-- 1 tkloczko tkloczko 447 Nov 14 2020 _quoting_c.pyi
-rw-r--r-- 1 tkloczko tkloczko 11498 Nov 14 2020 _quoting_c.pyx
-rw-r--r-- 1 tkloczko tkloczko 519 Nov 14 2020 _quoting.py
-rw-r--r-- 1 tkloczko tkloczko 6386 Nov 14 2020 _quoting_py.py
-rw-r--r-- 1 tkloczko tkloczko 36016 Nov 14 2020 _url.py
/home/tkloczko/rpmbuild/BUILDROOT/python-yarl-1.6.3-5.fc35.x86_64/usr/lib64/python3.8/site-packages/yarl/__pycache__:
total 128
-rw-r--r-- 1 tkloczko tkloczko 284 Jun 7 17:55 __init__.cpython-38.opt-1.pyc
-rw-r--r-- 1 tkloczko tkloczko 284 Jun 7 17:55 __init__.cpython-38.opt-2.pyc
-rw-r--r-- 1 tkloczko tkloczko 284 Jun 7 17:55 __init__.cpython-38.pyc
-rw-r--r-- 1 tkloczko tkloczko 478 Jun 7 17:55 _quoting.cpython-38.opt-1.pyc
-rw-r--r-- 1 tkloczko tkloczko 478 Jun 7 17:55 _quoting.cpython-38.opt-2.pyc
-rw-r--r-- 1 tkloczko tkloczko 478 Jun 7 17:55 _quoting.cpython-38.pyc
-rw-r--r-- 1 tkloczko tkloczko 4293 Jun 7 17:55 _quoting_py.cpython-38.opt-1.pyc
-rw-r--r-- 1 tkloczko tkloczko 4293 Jun 7 17:55 _quoting_py.cpython-38.opt-2.pyc
-rw-r--r-- 1 tkloczko tkloczko 4293 Jun 7 17:55 _quoting_py.cpython-38.pyc
-rw-r--r-- 1 tkloczko tkloczko 26831 Jun 7 17:55 _url.cpython-38.opt-1.pyc
-rw-r--r-- 1 tkloczko tkloczko 22032 Jun 7 17:55 _url.cpython-38.opt-2.pyc
-rw-r--r-- 1 tkloczko tkloczko 26831 Jun 7 17:55 _url.cpython-38.pyc
/home/tkloczko/rpmbuild/BUILDROOT/python-yarl-1.6.3-5.fc35.x86_64/usr/lib64/python3.8/site-packages/yarl-1.6.3-py3.8.egg-info:
total 44
-rw-r--r-- 1 tkloczko tkloczko 1 Jun 7 17:55 dependency_links.txt
-rw-r--r-- 1 tkloczko tkloczko 25050 Jun 7 17:55 PKG-INFO
-rw-r--r-- 1 tkloczko tkloczko 77 Jun 7 17:55 requires.txt
-rw-r--r-- 1 tkloczko tkloczko 861 Jun 7 17:55 SOURCES.txt
-rw-r--r-- 1 tkloczko tkloczko 5 Jun 7 17:55 top_level.txt |
|
I just realized the error Its a Pytest invocation error Invocation as module changes pythonpath That needs to be accounted for, for example by using a src folder Yarl does not A potential workaround is to invoke the tests in the test subdirectory |
|
@kloczek I wrote this elsewhere but have you tried https://src.fedoraproject.org/rpms/pyproject-rpm-macros? There's a good chance that it'll help you with this. OTOH @RonnyPfannschmidt is right, this is likely because pytest changes the import path. |
|
@webknjaz pytest does not, python -m does It creates a lot of issues im wondering about deprecation |
|
@RonnyPfannschmidt oh, I didn't realize that. I've always thought that it's probably something in FWIW I do like (and prefer) |
|
It has certain advantages, but messes up pythonpath So I'm very conflicted about it |
|
Maybe add a mandatory |
Hmm .. maybe I misunderstood intentions pointing on that package but that set of macros has nothing to do with pytest (?) I'm trying to use only setuptools and builder/pep517 + installer because Fedora macros are using pip which themselves has gigantic dependencies and by this in Fedora methodology is forces whole python stack build with additional boostrap cycle (which so far I was able to avoid in all places where Fedora python packages been thinking that it was unavoidable). In other words that approach creates non-planar dependencies graph which makes all that way more harder to maintain :/ |
Moment .. so what is the difference? |
with
No. You can achieve this by either using
Oh, it integrates tox but not pytest directly. So yes, you'll need to invoke it yourself, then. Maybe @hroncok or @encukou know better macros, I don't 🤷♂️. Still, you'll be better off using those macros to build from the source correctly.
The macro I pointed at doesn't. It implements extraction of PEP517 build deps on its own and generates dynamic build dependencies which is easier to maintain because you don't have to hardcode them in the spec file.
This sounds like you're talking about some other macros, perhaps older ones. The bootstrap complaint doesn't sound right either: the macros extract the build backend deps and turn them into fedora-packaged names so they can be extracted from src or nosrc rpm and installed after |
|
Note that in Fedora, We use |
To be hones I don't want any of those options. So looks like now pytest or "python -m pytest" are not able to work with $PYTHONPATH? So .. Q: how to solve that?
That depends on point of view what is better. |
That is Fedora problem .. not mine :) Fedora macro does not in few cases with LTO or with pytest which is trying to compile something during testing. |
From point of view someone like me who is using pytest mainly to package python stuff from non-root account I would expect exactly the same behaviour in both cases, and in both cases IMO should be used first $PYTHONPATH, than by default not project root but Only functional difference between use pytest script and |
In fact, it is your problem, not Fedora's. So I'll just back off. |
|
closing as user error when setting up python paths @nicoddemus i think we should start to consider deprecating |
So how it suppose to be tested using pytest stuff just installed in rpm buildroot? |
|
in your particular use-case - doing something like renaming the importable name in your cwd to something not mattering should be enough for example upstream a src layout (which no longer triggers the issue) |
It does work with
|
Maybe issue a recommendation to |
It is not entirely true. It is not only my particular use-case.
So rephrasing: it does not work because it adds own path on the front 😊 And another Q: why like cmake, meson., GNU autotools (when they are used to off-tree build or not) are able to organise testing without actual installation of just build resources and setuptools and other python tooling seems cannot use in-place just build files (typically under build/) and wants to use current directory or refuses to test just installed stuff in install prefix? Sorry for asking maybe even very dumb and many questions .. I'm only trying to understand whole approach since none of the available sources I can squeeze the answer (or even vector in which I should be looking for the answers).
Many of the modules have test units not under for example the tests/. Simple I have impression that it is kind of pytest inconsistency as it is mostly used after using setup tools which by default puts all stuff which on next stet will be installed under build and than some parts of the setuptools (like After rethinking one more time now I'm more or less convinced that use in Fedora %pytest macro (which at thhe momnent looks like blow): %pytest %{expand:\\\
CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\\\
PATH="%{buildroot}%{_bindir}:$PATH"\\\
PYTHONPATH="${PYTHONPATH:-%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib}}"\\\
PYTHONDONTWRITEBYTECODE=1\\\
%__pytest}$PYTHONPATH is kind of wrong and by default it should be using Using (somehow) Am I pointing in at least the right direction or not? If I'm not please .. can someone explain why? Thank you guys to all your time. |
This is half correct. The correct part is that the path gets prepended.
It is not necessary. It's just what happens when you invoke Python modules using
As Ronny mentioned earlier, there's also
Because you'll end up testing the wrong thing, not what the end-users will get. Also, note that it's highly discouraged to abuse
No, it shouldn't. It's an internal implementation detail of a certain backend (setuptools). You mustn't rely on it. And you mustn't assume that the project's build backend is setuptools. It could be anything (flit, poetry, a project's own in-tree backend). Each may put temporary build artifacts in different locations. Only rely on what's in the resulting artifact / resulting package install under site-packages.
I think the best place to start learning about Python packaging is https://packaging.python.org and you may ask related questions at https://discuss.python.org/c/packaging — this is where a lot of folks who know how this all works are active. There's also https://discord.com/invite/pypa for a more live chat and |
From python manual page: -m module-name
Searches sys.path for the named module and runs the corresponding .py file as a script.and .. [tkloczko@barrel SPECS]$ python3
Python 3.8.9 (default, Apr 7 2021, 13:42:48)
[GCC 11.0.1 20210324 (Red Hat 11.0.1-0)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/lib64/python38.zip', '/usr/lib64/python3.8', '/usr/lib64/python3.8/lib-dynload', '/usr/lib64/python3.8/site-packages', '/usr/lib/python3.8/site-packages']
>>>
[tkloczko@barrel SPECS]$ PYTHONPATH=. python3
Python 3.8.9 (default, Apr 7 2021, 13:42:48)
[GCC 11.0.1 20210324 (Red Hat 11.0.1-0)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/home/tkloczko/rpmbuild/SPECS', '/usr/lib64/python38.zip', '/usr/lib64/python3.8', '/usr/lib64/python3.8/lib-dynload', '/usr/lib64/python3.8/site-packages', '/usr/lib/python3.8/site-packages']
>>>So sys.path shows exactly what it suppose to show. In man page is as well -s Don't add user site directory to sys.path.Could |
I believe |
I believe this happens here https://github.com/python/cpython/blob/3fe921cd/Lib/runpy.py#L274 |
|
So there is no any way to run module without that upfront current directory??🤔 |
|
Yes, you can run the script called |
|
Is it possible to reopen this ticket? So again summary details about scenarion:
Here is example zmq + PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-zmq-22.1.0-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-zmq-22.1.0-2.fc35.x86_64/usr/lib/python3.8/site-packages
+ PYTHONDONTWRITEBYTECODE=1
+ /usr/bin/pytest -ra
=========================================================================== test session starts ============================================================================
platform linux -- Python 3.8.9, pytest-6.2.4, py-1.10.0, pluggy-0.13.1
benchmark: 3.4.1 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
rootdir: /home/tkloczko/rpmbuild/BUILD/pyzmq-22.1.0
plugins: forked-1.3.0, shutil-1.7.0, virtualenv-1.7.0, expect-1.1.0, httpbin-1.0.0, flake8-1.0.7, timeout-1.4.2, betamax-0.8.1, freezegun-0.4.2, case-1.5.3, isort-1.3.0, aspectlib-1.5.2, asyncio-0.15.1, toolbox-0.5, xprocess-0.17.1, aiohttp-0.3.0, checkdocs-2.7.0, mock-3.6.1, rerunfailures-9.1.1, requests-mock-1.9.3, cov-2.12.1, pyfakefs-4.5.0, cases-3.6.1, flaky-3.7.0, hypothesis-6.14.0, benchmark-3.4.1, xdist-2.3.0, Faker-8.8.1
collected 0 items / 1 error
================================================================================== ERRORS ==================================================================================
______________________________________________________________________ ERROR collecting test session _______________________________________________________________________
/usr/lib64/python3.8/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
<frozen importlib._bootstrap>:1014: in _gcd_import
???
<frozen importlib._bootstrap>:991: in _find_and_load
???
<frozen importlib._bootstrap>:961: in _find_and_load_unlocked
???
<frozen importlib._bootstrap>:219: in _call_with_frames_removed
???
<frozen importlib._bootstrap>:1014: in _gcd_import
???
<frozen importlib._bootstrap>:991: in _find_and_load
???
<frozen importlib._bootstrap>:961: in _find_and_load_unlocked
???
<frozen importlib._bootstrap>:219: in _call_with_frames_removed
???
<frozen importlib._bootstrap>:1014: in _gcd_import
???
<frozen importlib._bootstrap>:991: in _find_and_load
???
<frozen importlib._bootstrap>:975: in _find_and_load_unlocked
???
<frozen importlib._bootstrap>:671: in _load_unlocked
???
<frozen importlib._bootstrap_external>:783: in exec_module
???
<frozen importlib._bootstrap>:219: in _call_with_frames_removed
???
zmq/__init__.py:103: in <module>
from zmq import backend
zmq/backend/__init__.py:32: in <module>
raise original_error from None
zmq/backend/__init__.py:27: in <module>
_ns = select_backend(first)
zmq/backend/select.py:32: in select_backend
mod = import_module(name)
/usr/lib64/python3.8/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
zmq/backend/cython/__init__.py:6: in <module>
from . import (
E ImportError: cannot import name 'constants' from partially initialized module 'zmq.backend.cython' (most likely due to a circular import) (/home/tkloczko/rpmbuild/BUILD/pyzmq-22.1.0/zmq/backend/cython/__init__.py)
========================================================================= short test summary info ==========================================================================
ERROR - ImportError: cannot import name 'constants' from partially initialized module 'zmq.backend.cython' (most likely due to a circular import) (/home/tkloczko/rpmbui...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
============================================================================= 1 error in 0.68s =============================================================================All installed DSOs are on place |
|
No, this is off-topic and should be locked 🔒. I this comment #8731 (comment) I gave you the proper places for such discussions. P.S. FWIW it looks like Python picks up the local dir instead of the site-packages. This could happen for a million reasons and you need to inject a |
|
@kloczek this is again a different wrong test invocation on a package that has a structurally bad setup of the testsuite as inline to the code a different pytest invocation is needed to run/test it in the installation site i believe a im going to lock this issue now and urge you to reconsider how you interact with upstream issue trackers |
It is quite regular cases and there are many such modules which are producucing dururing
python setup.py buildcommand DSO loadable module for example using cython. As I wrote it is quite regular that such modules are failing on testing using pytest because pytest cannot locate DSO module.Such example could be
yarl(https://github.com/aio-libs/yarl/) but there are many more of themTo reproduce could be used below script:
In my case above fails with:
After
build it is producesbuild/lib.-/yarl/_quoting_c.cpython-*.soSomething is missing in such cases or it some bug in pytest?
Because it is very common case I suppose that it could be something wrong with pytest (?)
The text was updated successfully, but these errors were encountered: