python-scikit-misc fails to build with pytest 8. ==================================== ERRORS ==================================== ______________ ERROR collecting skmisc/loess/tests/test_loess.py _______________ skmisc/__init__.py:15: in <module> from skmisc.__config__ import show as show_config # noqa: F401 E ModuleNotFoundError: No module named 'skmisc.__config__' During handling of the above exception, another exception occurred: <frozen importlib._bootstrap_external>:995: in exec_module ??? <frozen importlib._bootstrap>:488: in _call_with_frames_removed ??? skmisc/__init__.py:20: in <module> raise ImportError('\n\n'.join([err.message, msg])) # type: ignore E AttributeError: 'ModuleNotFoundError' object has no attribute 'message' =========================== short test summary info ============================ ERROR skmisc/loess/tests/test_loess.py - AttributeError: 'ModuleNotFoundError... !!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!! =============================== 1 error in 0.07s =============================== https://docs.pytest.org/en/stable/changelog.html For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/thrnciar/pytest/fedora-rawhide-x86_64/07389667-python-scikit-misc/ For all our attempts to build python-scikit-misc with pytest 8, see: https://copr.fedorainfracloud.org/coprs/thrnciar/pytest/package/python-scikit-misc/ Let us know here if you have any questions. Pytest 8 is planned to be included in Fedora 41. And this bugzilla is a heads up before we merge new pytest into rawhide. For more info see a Fedora Change proposal https://fedoraproject.org/wiki/Changes/Pytest_8 We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
This appears to be quite a big change in behavior of pytest. I've seen this in another package I (co-)maintain. Here's the tree for scikit-misc: scikit-misc-0.3.1 ├── ci ├── doc │ ├── api.rst │ ├── changelog.rst │ ├── conf.py │ ├── index.rst │ ├── installation.rst │ ├── loess.rst │ ├── Makefile │ ├── sphinxext │ ├── _static │ ├── _templates │ └── theme ├── examples │ ├── loess-basic-usage.ipynb │ └── requirements-examples.txt ├── LICENSE ├── Makefile ├── meson.build ├── meson_options.txt ├── pyproject.toml ├── README.rst ├── requirements │ ├── build.txt │ ├── dev.txt │ ├── docs.txt │ └── release.txt ├── skmisc │ ├── _build_utils │ ├── __config__.py.in │ ├── _distributor_init.py │ ├── __init__.py │ ├── loess │ ├── meson.build │ └── _version.py.in ├── spin └── tools ├── build_theme.sh ├── deploy_documentation.sh ├── openblas_support.py └── wheels What happens with pytests >= 8 is that it's trying to import from skmisc/ which happens to be the name of the importable module as well. But that's of course the source directory for the module. And in this case the build backend is meson-python. With pytest < 8 passing `--import-mode=importlib` would solve this. That's also one of the parameters given in `pyproject.toml` (`tool.pytest.ini_options` table). But with pytest >= 8 that appears to be no longer sufficient. That feels a bit like a regression. The only workaround I have found so far is running the tests from an empty directory. In this case (and the previous one) I added mkdir empty && pushd empty ln -s ../skmisc/loess/tests . to the sec file. But that feels clumsy and unnecessary. Would you happen to have any information on the change of behavior using `--import-mode=importlib`?
Based on https://github.com/pytest-dev/pytest/issues/12194 and https://github.com/pytest-dev/pytest/pull/12208, it looks like this should be fixed in pytest 8.2.0.
Nice catch. Thanks! So, this seems to be related to doctests being enabled. IIRC, the other package had that enabled as well. It would be nice to have the fix backported or have pytest upgraded to >= 8.2.0.
Hmm... I upgraded pytest in COPR to 8.2.0 a day after it was released upstream. The linked build used 8.2.0. ============================= test session starts ============================== platform linux -- Python 3.12.3, pytest-8.2.0, pluggy-1.5.0 I've verified "the fix" is present in the sources. So there is probably some other culprit.
Hmm... I guess I will fall back to the workaround. If someone wants to dig further and report this upstream, be my guest. The last comment from the OP in the upstream ticket says the issue is not fixed, though the ticket has been closed. Not sure what's going on there.
Note to self: "[skip changelog]" prevents Bodhi from closing bugs.
(In reply to Sandro from comment #6) > Note to self: "[skip changelog]" prevents Bodhi from closing bugs. This makes sense, since Bodhi reads the changelog rather than the git history. Normally you want a changelog entry for each build, so [skip changelog] makes sense only if you’re not planning to do a build for that commit.
(In reply to Ben Beasley from comment #7) > (In reply to Sandro from comment #6) > > Note to self: "[skip changelog]" prevents Bodhi from closing bugs. > > This makes sense, since Bodhi reads the changelog rather than the git > history. Yes. And I almost expected it to happen. Although, Koji lists it on the build page: https://koji.fedoraproject.org/koji/buildinfo?buildID=2451711 > Normally you want a changelog entry for each build, so [skip changelog] > makes sense only if you’re not planning to do a build for that commit. Kinda. Following the recent discussion on the devel mailing list, I go by "Do I want to bother consumers of the package with this commit message?" Changes to the spec file that have no impact on the build result, for example, don't need to be listed in the changelog. In this case I thought this is minor enough and not changing the user facing part at all, so skip it. On the other hand, since I skipped changelog for both commits, it may raise the question why has the package been rebuilt.