Bug 1935212 - %_pyproject_builddir sometimes leaks to pytest collection
Summary: %_pyproject_builddir sometimes leaks to pytest collection
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pyproject-rpm-macros
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miro Hrončok
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-04 14:39 UTC by Miro Hrončok
Modified: 2021-07-09 14:55 UTC (History)
4 users (show)

Fixed In Version: pyproject-rpm-macros-0-41.fc35 pyproject-rpm-macros-0-42.fc34 pyproject-rpm-macros-0-42.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-04 01:07:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Miro Hrončok 2021-03-04 14:39:28 UTC
For the purpose of debuginfo/debugsource generation, we instruct pip to build out-of-tree builds inside a hidden directory in the builddir. This directory is %_pyproject_builddir (defined to .pyproject-builddir).

When pytest collects tests, it ignores hidden directories by default, because the `.*` pattern is ignored.

However, if upstream sets https://docs.pytest.org/en/stable/reference.html#confval-norecursedirs it replaces the default. If upstream does not explicitly list `.*`, hidden directories are not ignored. E.g. like this:

https://github.com/jaraco/jaraco.path/blob/49088ff54e73ef86f0ecd2206b07931b5801973a/pytest.ini#L2

    norecursedirs=dist build .tox .eggs

When this happens, pytest collects the files from both %_pyproject_builddir and the actual location, causing a mismatch:
    _____________________ ERROR collecting tests/test_path.py ______________________
    /usr/lib/python3.9/site-packages/_pytest/runner.py:311: in from_call
        result: Optional[TResult] = func()
    /usr/lib/python3.9/site-packages/_pytest/runner.py:341: in <lambda>
        call = CallInfo.from_call(lambda: list(collector.collect()), "collect")
    /usr/lib/python3.9/site-packages/_pytest/doctest.py:532: in collect
        module = import_path(self.fspath)
    /usr/lib/python3.9/site-packages/_pytest/pathlib.py:551: in import_path
        raise ImportPathMismatchError(module_name, module_file, path)
    E   _pytest.pathlib.ImportPathMismatchError: ('test_path', '/builddir/build/BUILD/jaraco.path-3.3.1/.pyproject-builddir/pip-req-build-dc2m0ci1/tests/test_path.py', PosixPath('/builddir/build/BUILD/jaraco.path-3.3.1/tests/test_path.py'))


The way to currently workaround this in the specfile is to use:

    %pytest --ignore %_pyproject_builddir

Or, in the case of pytest in tox:

    %tox -- -- --ignore %_pyproject_builddir

We should make sure this is not necessary.

Comment 1 Miro Hrončok 2021-03-04 14:43:28 UTC
A "simple" solution might be to pass PYTEST_ADDOPTS='--ignore %_pyproject_builddir' in %pytest and %tox.

https://docs.pytest.org/en/stable/reference.html#envvar-PYTEST_ADDOPTS


%tox is defined in pyproject-rpm-macros, the fix is trivial.


%pytest is defined in python-rpm-macros, so unless we want to spaghetti the two macro sets together, we can adapt it to do %{?_pytest_addopts:PYTEST_ADDOPTS='%{_pytest_addopts}'} and define %_pytest_addopts in pyproject_rpm_macros.

Comment 2 Lumír Balhar 2021-06-24 19:04:06 UTC
Another related issue I've just met is when %_pyproject_builddir contains a copy of conftest.py which defines CLI arguments for pytest - then the arguments are defined twice which leads to: ValueError: option names {'--run-integration'} already added.

Comment 3 Miro Hrončok 2021-06-24 19:13:44 UTC
(In reply to Lumír Balhar from comment #2)
> Another related issue I've just met is when %_pyproject_builddir contains a
> copy of conftest.py which defines CLI arguments for pytest - then the
> arguments are defined twice which leads to: ValueError: option names
> {'--run-integration'} already added.

Just to clarify, adding --ignore %_pyproject_builddir solves that problem as well?

Comment 4 Lumír Balhar 2021-06-25 07:29:49 UTC
(In reply to Miro Hrončok from comment #3)
> (In reply to Lumír Balhar from comment #2)
> > Another related issue I've just met is when %_pyproject_builddir contains a
> > copy of conftest.py which defines CLI arguments for pytest - then the
> > arguments are defined twice which leads to: ValueError: option names
> > {'--run-integration'} already added.
> 
> Just to clarify, adding --ignore %_pyproject_builddir solves that problem as
> well?

Yes, sorry for not mentioning it before.

Comment 6 Fedora Update System 2021-06-28 19:54:42 UTC
FEDORA-2021-872314c50e has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-872314c50e

Comment 7 Fedora Update System 2021-06-28 19:54:46 UTC
FEDORA-2021-f5e7993ed1 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f5e7993ed1

Comment 8 Fedora Update System 2021-06-28 19:55:43 UTC
FEDORA-2021-02f02941bb has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 9 Fedora Update System 2021-06-29 01:32:18 UTC
FEDORA-2021-872314c50e has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-872314c50e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-872314c50e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Fedora Update System 2021-06-29 02:09:43 UTC
FEDORA-2021-f5e7993ed1 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f5e7993ed1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f5e7993ed1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2021-06-29 16:30:15 UTC
FEDORA-2021-f5e7993ed1 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f5e7993ed1

Comment 12 Fedora Update System 2021-06-30 14:19:51 UTC
FEDORA-2021-f5e7993ed1 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f5e7993ed1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f5e7993ed1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2021-06-30 14:23:55 UTC
FEDORA-2021-872314c50e has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-872314c50e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-872314c50e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2021-07-04 01:07:15 UTC
FEDORA-2021-872314c50e has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 15 Fedora Update System 2021-07-08 01:07:45 UTC
FEDORA-2021-f5e7993ed1 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.