nedbat
commented
2 years ago It looks like coverage can't find a place to write a .pth file. Are none of the directories in sys.path writable?
Closed kloczek closed 1 year ago
nedbat
commented
2 years ago It looks like coverage can't find a place to write a .pth file. Are none of the directories in sys.path writable?
kloczek
commented
2 years ago Just found new 6.4 version and tested that using strace
Question is why in this case pytest executed from non-root account is trying to write something in system image? 🤔
Extracted all Permission denied strace lines:
openat(AT_FDCWD, "/usr/lib64/python3.8/site-packages/touch_none.it", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/usr/lib/python3.8/site-packages/touch_none.it", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/usr/lib/python3.8/site-packages/touch_none.it", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)I have already +940 modules packaged as rpm packages and in 8/9 of those packaging procedures as part pf the packaging procedures pytest is used and cannot find in the logs similar case 🤔
kloczek
commented
2 years ago Hmm just tested ..
[tkloczko@devel-g2v coveragepy-6.4]$ grep -r touch_none
[tkloczko@devel-g2v coveragepy-6.4]$ grep -r touch_none /usr/lib/python3.8/site-packages/ /usr/lib64/python3.8/
[tkloczko@devel-g2v coveragepy-6.4]$Any update? Just tested 6.4.1 and pytest is failing the same way.
nedbat
commented
2 years ago "touch_none.it" is a file name I try to write to see if I can write a .pth file that is needed to run all the coverage.py tests. Can you print the contents of sys.path, and also the "ls -l" for each of those directories?
As a drastic step, I suppose the coverage.py test suite could skip tests that need the .pth file if it couldn't be written.
kloczek
commented
2 years ago "touch_none.it" is a file name I try to write to see if I can write a .pth file that is needed to run all the coverage.py tests. Can you print the contents of sys.path, and also the "ls -l" for each of those directories?
OK .. but which one directories? 😋
sys.path is altersd by env variable
+ PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-coverage-6.3.3-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-coverage-6.3.3-2.fc35.x86_64/usr/lib/python3.8/site-packagesAs a drastic step, I suppose the coverage.py test suite could skip tests that need the .pth file if it couldn't be written.
Issue is that in this case pytest is failing on collecting units 😃 AFAIK skipping is only possible after finishing that stage.
nedbat
commented
2 years ago OK .. but which one directories? 😋 sys.path is altersd by env variable
I'm interested in the sys.path that coverage.py is using, so including the environment variable. Can you add some print statements to the code to see what directories it's considering, and what files are in them?
If we need to skip tests, we'd do it by changing the failure to a flag, and use the flag to skip. But it would be better to find a new place for the .pth file.
kloczek
commented
2 years ago Just tesated 6.4.2. Looks like it is better now becaus pytest is able to collect unit ad start testing. However it shows fails and errors.
kloczek
commented
2 years ago Just FTR: tested 6.4.3 and result still is the same.
kloczek
commented
2 years ago OK .. but which one directories? 😋 sys.path is altersd by env variable
I'm interested in the sys.path that coverage.py is using, so including the environment variable. Can you add some print statements to the code to see what directories it's considering, and what files are in them?
If we need to skip tests, we'd do it by changing the failure to a flag, and use the flag to skip. But it would be better to find a new place for the .pth file.
Can you drop patch with such instrumentation?
nedbat
commented
2 years ago I added some quick verbose debugging in branch nedbat/debug-1373. Install it like this:
pip install git+https://github.com/nedbat/coveragepy@nedbat/debug-1373then /tmp/coverage_pth_files.txt has details.
kloczek
commented
1 year ago Here is result or 7.0.1 + https://github.com/nedbat/coveragepy/commit/54ea97a3afb27a166a01021c3d2e1fecb8d83551
kloczek
commented
1 year ago Hmm .. so looks like test suite is trying to write files in python sitelib drecory 🤔
nedbat
commented
1 year ago Yes, the test suite wants to be able to write .pth files to test some situations that need them. We have a few options here:
1) You give me very very explicit specific directions about how to do what you are doing, so I can understand it better. 2) I update the coverage.py test suite to skip tests if a pth place couldn't be found. I'm not sure how many that would be, and how much confidence we would lose.
I would prefer #1.
kloczek
commented
1 year ago May I ask why test suite is trying to write something in system sitelib directory? 🤔
nedbat
commented
1 year ago May I ask why test suite is trying to write something in system sitelib directory? 🤔
The test suite is trying to write a .pth file somewhere in the path, because coverage.py supports using a .pth file to start coverage for subprocesses. If I comment out the code that is causing this headache, these tests fail:
FAILED tests/test_process.py::ProcessStartupWithSourceTest::test_pth_and_source_work_together[main---m] - AssertionError: File '.coverage' should exist
FAILED tests/test_process.py::ProcessStartupWithSourceTest::test_pth_and_source_work_together[sub-pkg--m] - AssertionError: File '.coverage' should exist
FAILED tests/test_process.py::ProcessStartupWithSourceTest::test_pth_and_source_work_together[sub--] - AssertionError: File '.coverage' should exist
FAILED tests/test_process.py::ProcessStartupWithSourceTest::test_pth_and_source_work_together[main-pkg--m] - AssertionError: File '.coverage' should exist
FAILED tests/test_process.py::ProcessStartupWithSourceTest::test_pth_and_source_work_together[sub-pkg-] - AssertionError: File '.coverage' should exist
FAILED tests/test_process.py::ProcessStartupWithSourceTest::test_pth_and_source_work_together[sub---m] - AssertionError: File '.coverage' should exist
FAILED tests/test_process.py::ProcessStartupTest::test_subprocess_with_pth_files - assert 100 == 3
FAILED tests/test_process.py::ProcessStartupWithSourceTest::test_pth_and_source_work_together[main-pkg-] - AssertionError: File '.coverage' should exist
FAILED tests/test_process.py::ProcessStartupWithSourceTest::test_pth_and_source_work_together[main--] - AssertionError: File '.coverage' should exist
FAILED tests/test_process.py::ProcessStartupTest::test_subprocess_with_pth_files_and_parallel - KeyError: 'sub.py'May I ask why you don't have a writable directory in sys.path?
kloczek
commented
1 year ago May I ask why you don't have a writable directory in sys.path?
Please have a look one more time on first two lines of the log which I've dropped oppening ticket
+ PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-coverage-6.3.3-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-coverage-6.3.3-2.fc35.x86_64/usr/lib/python3.8/site-packages
+ /usr/bin/pytest -raIn $PYTHONPATH is passed directory with write access however that directory should not be used to write anything else on testing beause it will affect final content of the rpm package generated out of </install/prefix>.
nedbat
commented
1 year ago @kloczek I really appreciate that you are persisting with this. Please keep i mind that I know nothing about how rpm packages are made.
Please have a look one more time on first two lines of the log...
What in those lines would tell me that the directories aren't writable?
In $PYTHONPATH is passed directory with write access however that directory should not be used to write anything else...
If it is writable, then what is making the test setup fail? It seems the directory is not writable.
kloczek
commented
1 year ago Trust me this issue has nothing to do with rpm .. don't worry about that I'm packaging 'coveragepy`😄
If it is writable, then what is making the test setup fail? It seems the directory is not writable.
Please have look one more time on the output of the pytest with instrumentation patch which you've prepared.
In the output it is clarly wisible that test suite is not trying to write anything in /home/tkloczko/rpmbuild/BUILDROOT/python-coverage-6.3.3-2.fc35.x86_64/usr/lib64/python3.8/site-packages
nedbat
commented
1 year ago I forget exactly why, but coverage.py will only try writing a .pth file in a directory if there's already a .pth file there. Can you try touching a .pth file in that writable directory?
kloczek
commented
1 year ago Tested that and looks like first time ever pytest started without internal error however I see now a lot of failing units Here is list of installed modules in build env
kloczek
commented
1 year ago Things like "python -m pip install " shout be replced by "pip install ".
I have no python executable and rinning python -m foo should not be used because python in such cases adds current irectory to sys.path which alwaysis nothing more than asking for troubles ..
Only this will bring few units to the working stata 😋
Now question only os why this .. why that assumption with only try writing a .pth file in a directory if there's already a .pth file there was necessary? 🤔 Adnd second is: it is really necessary to write some files to the sitelib? Fidling outside /tmp or source tree looks a bit odd .. 🤔
kloczek
commented
1 year ago I'm going add in my packaging procedure tempporary those failing units to --deselect list to have some working baseline.
nedbat
commented
1 year ago I can't reproduce what you are seeing. Can you give me exact steps to reproduce your scenario?
kloczek
commented
1 year ago Excact steps are listed in descriptio openig this ticket. Just in case .. build and testing is performed fron non-root account.
kloczek
commented
1 year ago Just tested 7.2.1. Here is pytest output:
kloczek
commented
1 year ago Looks like python -m foo still is in use.
kloczek
commented
1 year ago Here is propose of the patch whci replaces use python by use sys.executable or <module_wrapper_script> instead python -m module if such script exist.
--- a/tests/test_process.py
+++ b/tests/test_process.py
@@ -653,7 +653,7 @@
# module, like it used to:
# $ python -m coverage
# Code coverage for Python. Use '__main__.py help' for help.
- out = self.run_command("python -m coverage")
+ out = self.run_command("coverage")
assert "Use 'coverage help' for help" in out
@@ -676,7 +676,7 @@
def test_coverage_run_is_like_python(self) -> None:
with open(TRY_EXECFILE) as f:
self.make_file("run_me.py", f.read())
- expected = self.run_command("python run_me.py")
+ expected = self.run_command(sys.executable, "run_me.py")
actual = self.run_command("coverage run run_me.py")
self.assert_tryexecfile_output(expected, actual)
@@ -689,7 +689,7 @@
def test_coverage_run_dashm_is_like_python_dashm(self) -> None:
# These -m commands assume the coverage tree is on the path.
- expected = self.run_command("python -m process_test.try_execfile")
+ expected = self.run_command(sys.executable, "-m process_test.try_execfile")
actual = self.run_command("coverage run -m process_test.try_execfile")
self.assert_tryexecfile_output(expected, actual)
@@ -705,7 +705,7 @@
with open(TRY_EXECFILE) as f:
self.make_file("with_main/__main__.py", f.read())
- expected = self.run_command("python -m with_main")
+ expected = self.run_command(sys.executable, "-m with_main")
actual = self.run_command("coverage run -m with_main")
self.assert_tryexecfile_output(expected, actual)
@@ -714,7 +714,7 @@
self.make_file("with_main/__main__.py", f.read())
self.make_file("with_main/__init__.py", "")
- expected = self.run_command("python -m with_main")
+ expected = self.run_command(sys.executable, "-m with_main")
actual = self.run_command("coverage run -m with_main")
self.assert_tryexecfile_output(expected, actual)
@@ -725,7 +725,7 @@
--source machinery to know and respect the original name.
"""
# These -m commands assume the coverage tree is on the path.
- expected = self.run_command("python -m process_test.try_execfile")
+ expected = self.run_command(sys.executable "-m process_test.try_execfile")
actual = self.run_command(
"coverage run --source process_test.try_execfile -m process_test.try_execfile"
)
@@ -745,7 +745,7 @@
disable_warnings = module-not-measured
""")
# These -m commands assume the coverage tree is on the path.
- expected = self.run_command("python -m process_test.try_execfile")
+ expected = self.run_command(sys.executable "-m process_test.try_execfile")
actual = self.run_command(
"coverage run --source process_test -m process_test.try_execfile"
)
@@ -780,7 +780,7 @@
with open(TRY_EXECFILE) as f:
self.make_file("sub/run_me.py", f.read())
- expected = self.run_command("python -m sub.run_me")
+ expected = self.run_command(sys.executable, "-m sub.run_me")
actual = self.run_command("coverage run -m sub.run_me")
self.assert_tryexecfile_output(expected, actual)
@@ -788,7 +788,7 @@
# https://github.com/nedbat/coveragepy/issues/207
self.make_file("package/__init__.py", "print('init')")
self.make_file("package/__main__.py", "print('main')")
- expected = self.run_command("python -m package")
+ expected = self.run_command(sys.executable, "-m package")
actual = self.run_command("coverage run -m package")
assert expected == actual
@@ -830,10 +830,10 @@
print(thing.SOMETHING)
""")
# If this test fails, it will be with "can't import thing".
- out = self.run_command("python run_coverage.py run how_is_it.py")
+ out = self.run_command(sys.executable, "run_coverage.py run how_is_it.py")
assert "hello-xyzzy" in out
- out = self.run_command("python -m run_coverage run how_is_it.py")
+ out = self.run_command(sys.executable, "-m run_coverage run how_is_it.py")
assert "hello-xyzzy" in out
@pytest.mark.skipif(env.WINDOWS, reason="Windows can't make symlinks")
@@ -1003,7 +1003,7 @@
def assert_pydoc_ok(self, name: str, thing: Any) -> None:
"""Check that pydoc of `name` finds the docstring from `thing`."""
# Run pydoc.
- out = self.run_command("python -m pydoc " + name)
+ out = self.run_command("pydoc " + name)
# It should say "Help on..", and not have a traceback
assert out.startswith("Help on ")
assert "Traceback" not in outpytest output with above patch
kloczek
commented
1 year ago Sorry patch is wrong.
Nevertheless instead using hardcoded python exacutable name it should be used sys.executable.
nedbat
commented
1 year ago Excact steps are listed in descriptio openig this ticket.
I'm sorry, I don't know how to reproduce what you are seeing. Can you provide very specific detailed steps for reproducing the problem. Looking at the bullets at the top of this issue, I don't know what repo/directory you are using. I don't know what "install .whl file in </install/prefix>" means.
kloczek
commented
1 year ago I don't know what "install .whl file in </install/prefix>" means.
for example python -m installer --destdir=/tmp/coveragepy/ dist/coveragepy*.whl and than pass that base directory in $PYTHONPATH. You can use as well for that pip.
BTW jsut tested 7.2.3 and here is updated pytest output
kloczek
commented
1 year ago Test suite complains about missing covmodzip1 in my buildenv hoawever I don't see that module on pypi 🤔
kloczek
commented
1 year ago Just FTR updated pytest output on testing 7.2.5
nedbat
commented
1 year ago @kloczek I see you are still interested enough to re-test this on new versions of coverage.py. What I need are very very very specific instructions about how to reproduce it. What exact repo should I clone? What exact commands should I type to see what you are seeing? What versions of packages do you have installed? In what version of Python?
kloczek
commented
1 year ago Just please try to execute in project source root directory something like below:
python3 -sBm build -w --no-isolation python3 -sBm installer dist/*.whl --destdir /tmp/coveragepy PYTHONPATH=/tmp/coveragepy/$(python3 -Ic "import sysconfig; print(sysconfig.get_path('purelib'))") pytest
Instead installer module ypu can use pip comman to unpack generated .whl into /tmp/coveragepy
kloczek
commented
1 year ago First issue which needs to be sorted out is hardcoded python executable name (I have only python3).
As I wrote sys.executable should be used always when python executable name is needed.
nedbat
commented
1 year ago I'm open to suggestions about how to make the tests runnable in more environments, but there's a limit to how complex I will make things.
I already use sys.executable to run Python: https://github.com/nedbat/coveragepy/blob/31c216b67ffb21c589fd39b55fe1bbd26d5bf705/tests/coveragetest.py#L428-L434
Do you have specific changes to suggest?
kloczek
commented
1 year ago Look .. that wherenever is necessary to use python executable its name ishoud be not used hardcoded python but what rerurns sys.executable .. not conditionally but allways.
[tkloczko@pers-jacek coveragepy-7.2.5]$ grep -r "python " tests
tests/balance_xdist_plugin.py:# python -c "from tests.balance_xdist_plugin import show_worker_times as f; f()"
tests/coveragetest.py: # Use the real name of our own executable. So "python foo.py" might
tests/modules/process_test/try_execfile.py: $ python try_execfile.py
tests/test_config.py: python igor.py zip_mods
tests/test_debug.py: python platform implementation executable
tests/test_filereporter.py:from coverage.python import PythonFileReporter
tests/test_html.py: self.make_file("innocuous.html", "<h1>This isn't python at all!</h1>")
tests/test_html.py: self.make_file("liar.html", "{# Whoops, not python code #}")
tests/test_oddball.py: status, out = self.run_command_status("python main.py")
tests/test_oddball.py: status, out = self.run_command_status("python atexit_gettrace.py")
tests/test_phystokens.py:from coverage.python import get_python_source
tests/test_plugins.py: # A plugin that measures, but then wants built-in python reporting.
tests/test_process.py: out = self.run_command("python envornot.py")
tests/test_process.py: out2 = self.run_command("python throw.py")
tests/test_process.py: status2, out2 = self.run_command_status("python exit.py")
tests/test_process.py: status2, out2 = self.run_command_status("python exit_none.py")
tests/test_process.py: py_out = self.run_command("python showtrace.py")
tests/test_process.py: out = self.run_command("python hello.py")
tests/test_process.py: out = self.run_command("python -X frozen_modules=off -m coverage run -L getenv.py")
tests/test_process.py: out = self.run_command("python allok.py")
tests/test_process.py: out = self.run_command("python run_twice.py")
tests/test_process.py: # $ python -m coverage
tests/test_process.py: out = self.run_command("python -m coverage")
tests/test_process.py: expected = self.run_command("python run_me.py")
tests/test_process.py: expected = self.run_command("python sub/overthere/prog.py")
tests/test_process.py: expected = self.run_command("python -m process_test.try_execfile")
tests/test_process.py: expected = self.run_command("python with_main")
tests/test_process.py: expected = self.run_command("python -m with_main")
tests/test_process.py: expected = self.run_command("python -m with_main")
tests/test_process.py: expected = self.run_command("python -m process_test.try_execfile")
tests/test_process.py: expected = self.run_command("python -m process_test.try_execfile")
tests/test_process.py: expected = self.run_command("python myscript")
tests/test_process.py: expected = self.run_command("python -m sub.run_me")
tests/test_process.py: expected = self.run_command("python -m package")
tests/test_process.py: expected = self.run_command("python run_me.py")
tests/test_process.py: actual = self.run_command(f"python {cov_main} run run_me.py")
tests/test_process.py: out = self.run_command("python run_coverage.py run how_is_it.py")
tests/test_process.py: out = self.run_command("python -m run_coverage run how_is_it.py")
tests/test_process.py: py_st, py_out = self.run_command_status("python excepthook.py")
tests/test_process.py: py_st, py_out = self.run_command_status("python excepthook_exit.py")
tests/test_process.py: py_st, py_out = self.run_command_status("python excepthook_throw.py")
tests/test_process.py: out = self.run_command("python -m pydoc " + name)
tests/test_process.py: 1. -m versus a simple script argument (for example, `python myscript`),
tests/test_process.py: cmd = "python -m %s" % fullname('main')
tests/test_process.py: cmd = "python %s" % path('main.py')
tests/test_python.py:from coverage.python import get_zip_bytes, source_for_file
tests/test_setup.py: "python setup.py --description --version --url --author"
tests/test_summary.py: self.make_file("mycode.py", "This isn't python at all!")
tests/test_summary.py: self.make_file("accented\xe2.py", "This isn't python at all!")
tests/test_summary.py: self.make_file("mycode.py", "This isn't python at all!")
tests/test_summary.py: self.make_file("mycode.html", "<h1>This isn't python at all!</h1>")
tests/test_summary.py: # This is a python file though it doesn't look like it, like a main script.
tests/test_testing.py: out_lines = self.run_command("python showme.py").splitlines()
tests/test_testing.py: out = self.run_command("python outputs.py")
tests/test_venv.py: run_command("python -m venv venv")
tests/test_venv.py: "python -m pip install " +
tests/test_venv.py: "python -m coverage",
tests/test_venv.py: run_in_venv("python -m pip install .")So as you see in in many places where command_name is not used ans is used hardcoded python.
All pip and coverage executions not done over python -m <module>ane should be uses wrapper scripts all because when module is executed over python -m <foo> current directory is added sys.path.
kloczek
commented
1 year ago With below grep output it is better vidsible
[tkloczko@pers-jacek coveragepy-7.2.5]$ grep -r 'run_command_status("python' tests
tests/test_oddball.py: status, out = self.run_command_status("python main.py")
tests/test_oddball.py: status, out = self.run_command_status("python atexit_gettrace.py")
tests/test_process.py: status2, out2 = self.run_command_status("python exit.py")
tests/test_process.py: status2, out2 = self.run_command_status("python exit_none.py")
tests/test_process.py: py_st, py_out = self.run_command_status("python excepthook.py")
tests/test_process.py: py_st, py_out = self.run_command_status("python excepthook_exit.py")
tests/test_process.py: py_st, py_out = self.run_command_status("python excepthook_throw.py")If you look at the code I linked you to earlier, it's the run_command_status function, which replaces the first word "python" with sys.executable. The run_command function calls run_command_status. So all of those function calls are already using sys.executable.
kloczek
commented
1 year ago Please have look one more time on pytest output which I've provides. You can find there fragments like
# Install everything.
> run_in_venv(
"python -m pip install " +
"./third_pkg " +
"-e ./another_pkg " +
"-e ./bug888/app -e ./bug888/plugin " +
COVERAGE_INSTALL_ARGS
)Where run_command_status not used.
nedbat
commented
1 year ago Are you sure changing those uses will fix your problem? run_in_venv runs those commands in a venv we just created.
kloczek
commented
1 year ago So why it fails? 🤔
nedbat
commented
1 year ago Maybe we can go back to your original goal. Why are you running "pytest" directly? There are steps needed to get the world right for the tests. Tox does this for me. If you use tox, there are still a few failures, but only five:
kloczek
commented
1 year ago As I wrote I'm building rpm package with your module. In such case because such build is done from non-root account it is no possible to install module in python system sitearch and sitelib trees. Only way to test package is to use build root tree where are installed all files which will be used to finally assemble rpm package and run pytest with $PYTHONPATH env variable with added necessary paths. Using venvs in such cases does not make eny sense because build is done in system image in which are installed only resources listed in build requirements. In other woords what in ststem image it will be in ixacrly the same versionslike in potentially created venv.
Above methodology is widely used on building not only rpm but Debian deb packages as well.
Opening ticket I've dropped exact list of modules installed in build env it that set is result of installing only what is listed in rpm spec file BuildRequires.
In case of your coverage module such list looks like below:
BuildRequires: gcc
BuildRequires: python3-devel
BuildRequires: python3dist(build)
BuildRequires: python3dist(installer)
BuildRequires: python3dist(setuptools)
BuildRequires: python3dist(sphinx)
BuildRequires: python3dist(sphinxcontrib-restbuilder)
BuildRequires: python3dist(sphinxcontrib-spelling)
BuildRequires: python3dist(sphinx-rst-builder)
BuildRequires: python3dist(sphinx-rtd-theme)
BuildRequires: python3dist(sphinx-tabs)
BuildRequires: python3dist(wheel)
# CheckRequires:
BuildRequires: python3dist(flaky)
BuildRequires: python3dist(hypothesis)
BuildRequires: python3dist(pytest)
BuildRequires: python3dist(pytest-xdist)What is not on above list have been installed as above install time dependencies.
To assembly python env is not used pypi repoo. Are used only packages already build and provided as repository.
On instilling for example python3dist(build) (which is in python-build rpm package) are installed all other packages which are listed in install dependencies (rpm Requires).
If you need more details about context feel free to ask .. I'll try to explain everything as good as I only cane 😋
nedbat
commented
1 year ago I know nothing about rpm packages. I don't know where the list of BuildRequires came from. Why are hypothesis and sphinx-tabs in the list, but tox is not? Why don't we just add tox to the list if it's required to run the tests?
The alternative is to use the tox.ini as a model of what is needed to configure the world properly to run the tests. Simply running "pytest" isn't going to be enough.
supakeen
commented
1 year ago @kloczek For which distribution are you building this RPM?
nedbat
commented
1 year ago @kloczek Fedora is building rpm's, maybe you can see how they are doing it: https://src.fedoraproject.org/rpms/python-coverage
kloczek
commented
1 year ago rpm has nothing to do here as this tooling is only part oof broader context which I've described you why I'm doing thing isn exact way to give you possibility to understand fact that behind those steps are some rational causes. Only this and nothing more 😋 What is relevant here is build (use pep517 based build) install (unpack generated .whl in </install/prefix> and testing methdology (use pytest with set $PYTHONPATH).
@kloczek For which distribution are you building this RPM?
My own. That distribution however shares almost 100% methodologies used in Fedora. On Python packaging are it shares 100% of those methodologies. In other words if you want to test this issue you can grab fedora image ind play which procedure which I've described.
@kloczek Fedora is building rpm's, maybe you can see how they are doing it: https://src.fedoraproject.org/rpms/python-coverage
If you will look closer you woul find that Fedora spec file for coverage module filehttps://src.fedoraproject.org/rpms/python-coverage/blob/rawhide/f/python-coverage.spec:
That is the problem of the Fedora that as all community maintained disstribution it is problem with use common methodologies as bradly as it is ony possible. More time takes poitless discussion on introducing such methodologires, voting nad approving thhan actual change which could be introduced in matter of minutes on scale of all packages.
In my case Ihave 100% python packjages with trst suite execution, 100% use pep517 and few more other thing which nine in Fedora are aware that it is possible to do like replace pip by installer to unpack .whl in </install/prefix> (pip has waay bigger install time depenmdencies than installer).
Fedora python-coverage.spec file has been added first time +13 years ago and maintainer of that package is really lagging even in context of use of alredy approved/recommended Fedora packaging methodologies.
To give you example what I've done here is my python-coverage.spec file
With that I csn for example quickly test is new version still have the same issues with failing test units.
kloczek
commented
1 year ago Going back to the subject .. As you are able nowreporoduce some of those issues .. any conclutions? 😋
I'm trying to package your module as an rpm package. So I'm using the typical PEP517 based build, install and test cycle used on building packages from non-root account.
python3 -sBm build -w --no-isolationbuildwith--no-isolationI'm using during all processes only locally installed modulesHere is pytest output:
List of module sinstalled in build env