Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin file tracer never gets called with source files #1325

Open
Timtam opened this issue Feb 19, 2022 · 1 comment
Open

Plugin file tracer never gets called with source files #1325

Timtam opened this issue Feb 19, 2022 · 1 comment
Labels
bug Something isn't working question Further information is requested

Comments

@Timtam
Copy link

Timtam commented Feb 19, 2022

The issue seems to be rather complex. The more in-depth explanation follows at the end of the usual bug report content.

Describe the bug

A plugin's file_tracer method doesn't seem to get called with any file of a package that should be measured, but relevant files are showing up in the coverage report anyway, causing an error like this:

coverage.exceptions.DataError: Can't add file tracer data for unmeasured file 'C:\scripts\Bass4Py\Bass4Py\bass\bass.pxd'

To Reproduce

  1. What version of Python are you using?

Python 3.8.2

  1. What version of coverage.py shows the problem? The output of coverage debug sys is helpful.
-- sys -------------------------------------------------------
               coverage_version: 6.3.1
                coverage_module: c:\users\toni\.virtualenvs\bass4py-lj7zysza\lib\site-packages\coverage\__init__.py
                         tracer: -none-
                        CTracer: available
           plugins.file_tracers: Cython.Coverage.Plugin
            plugins.configurers: Cython.Coverage.Plugin
      plugins.context_switchers: -none-
              configs_attempted: .coveragerc
                   configs_read: C:\scripts\Bass4Py\.coveragerc
                    config_file: C:\scripts\Bass4Py\.coveragerc
                config_contents: b'[run]\r\nplugins = Cython.Coverage\r\nsource = Bass4Py\r\nomit =\r\n    tests\r\n    *__init__.py'
                      data_file: -none-
                         python: 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit (AMD64)]
                       platform: Windows-10-10.0.22000-SP0
                 implementation: CPython
                     executable: c:\users\toni\.virtualenvs\bass4py-lj7zysza\scripts\python.exe
                   def_encoding: utf-8
                    fs_encoding: utf-8
                            pid: 27908
                            cwd: C:\scripts\Bass4Py
                           path: C:\Users\Toni\.virtualenvs\Bass4Py-Lj7zYsZA\Scripts\coverage.exe
                                 c:\users\toni\.virtualenvs\bass4py-lj7zysza\scripts\python38.zip
                                 C:\Users\Toni\.pyenv\pyenv-win\versions\3.8.2\DLLs
                                 C:\Users\Toni\.pyenv\pyenv-win\versions\3.8.2\lib
                                 C:\Users\Toni\.pyenv\pyenv-win\versions\3.8.2
                                 c:\users\toni\.virtualenvs\bass4py-lj7zysza
                                 c:\users\toni\.virtualenvs\bass4py-lj7zysza\lib\site-packages
                    environment: PIP_PYTHON_PATH = c:\users\toni\.local\pipx\venvs\pipenv\scripts\python.exe
                                 PYENV_HOME = C:\Users\Toni\.pyenv\pyenv-win\
                                 PYTHONDONTWRITEBYTECODE = 1
                                 TEMP = C:\Users\Toni\AppData\Local\Temp
                                 TMP = C:\Users\Toni\AppData\Local\Temp
                   command_line: C:\Users\Toni\.virtualenvs\Bass4Py-Lj7zYsZA\Scripts\coverage debug sys
                sqlite3_version: 2.6.0
         sqlite3_sqlite_version: 3.28.0
             sqlite3_temp_store: 0
        sqlite3_compile_options: COMPILER=msvc-1916; ENABLE_FTS4; ENABLE_FTS5
                                 THREADSAFE=1
  1. What versions of what packages do you have installed? The output of pip freeze is helpful.
aenum==2.2.1
alabaster==0.7.12
appdirs==1.4.4
atomicwrites==1.4.0
attrs==21.4.0
Babel==2.9.1
black==22.1.0
bleach==4.1.0
certifi==2021.10.8
chardet==4.0.0
charset-normalizer==2.0.12
click==8.0.3
colorama==0.4.4
coverage==6.3.1
Cython==3.0.0a10
docutils==0.17.1
idna==3.3
imagesize==1.3.0
importlib-metadata==4.11.1
iniconfig==1.1.1
Jinja2==3.0.3
keyring==23.5.0
MarkupSafe==2.1.0
mypy==0.790
mypy-extensions==0.4.3
packaging==21.3
pathspec==0.9.0
pkginfo==1.8.2
platformdirs==2.5.0
pluggy==1.0.0
py==1.11.0
Pygments==2.11.2
pyparsing==3.0.7
pytest==7.0.1
pytest-cov==3.0.0
pytest-order==1.0.1
pytz==2021.3
pywin32-ctypes==0.2.0
readme-renderer==32.0
regex==2021.7.1
requests==2.27.1
requests-toolbelt==0.9.1
rfc3986==2.0.0
six==1.16.0
snowballstemmer==2.2.0
Sphinx==4.4.0
sphinx-autodoc-typehints==1.17.0
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==2.0.0
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.5
toml==0.10.2
tomli==2.0.1
tqdm==4.62.3
twine==3.8.0
typed-ast==1.4.2
typing-extensions==4.1.1
urllib3==1.26.8
webencodings==0.5.1
zipp==3.7.0
  1. What code shows the problem? Give us a specific commit of a specific repo that we can check out. If you've already worked around the problem, please provide a commit before that fix.

Timtam/Bass4Py@d02f095

  1. What commands did you run?

Both ways, running either within pytest-cov and pure coverage, yield the same result. Either:

coverage run -m pytest

or

pytest --cov-config=.coveragerc --cov

Expected behavior

I'd expect coverage to properly measure my Cython code which should be enabled with the help of the Cython.Coverage plugin.

Additional context

i'm currently in the process of tracking down an issue that exists since approximately Coverage.py 5.0 with a plugin which allows Coverage to measure Cython code, which can be found here: https://github.com/cython/cython/blob/master/Cython/Coverage.py

The issue is known to Cython's developers for quite a while now and i'm not sure where to even start searching and hope you can help me a bit further. The relevant issue can be found here: cython/cython#3515

The situation is as follows:

I set up everything correctly (I hope), means that I prepared everything Cython-wise first and set up a .coveragerc file next, as you can see in the bug report above. I then make sure to compile the project with debug enabled, allowing Cython to provide any information necessary for coverage / Cython.Coverage to work with. Running coverage afterwards yields the error shown above.

I started digging into the Cython.Coverage plugin and tried to debug the file_tracer method, which I think should be called for any possible file which can be measured, which deffinitely happens, but it only gets called with site-packages like pytest and others, but never gets called with files from my actual project and never returns an actual FileTracer object to coverage.py to further work with. I'm thus confused that coverage still found a .pxd file to work with, because I think that the Cython.Coverage plugin isn't responsible for that incident. I wasn't able to find any information where coverage was able to detect the pxd file, which is deffinitely correct, but since Cython.Coverage did never return a FileTracer object, coverage obviously doesn't know how to further trace this file type. I tried to track the issue down and ended up within the C Tracer and now think that I might find the issue much faster if I can get some help from you instead of debugging through that piece of the coverage project.

Since building the project i'm working on can be rather complicated due to external dependencies and such, I provided a debug build of the Cython module in question for Python 3.8 amd64 Windows and will try to attach it to this issue so that you can download and test with it if you like. GitHub doesn't allow attaching whl files however, so I provided a download link. Hope thats okay.

https://web.cubbit.io/link/#7b1e965a-84d0-42ed-b955-bfe35f2dad10!LkZm1MtOAWSvhQrhNb3ZXMUhCA6zVdghjXxDI9aZTBA!8TINwrWKR/KE7IMroFOlhw

As I already mentioned, the issues seem to have started around the time of coverage getting updated to version 5.0. Those of you who are much more familiar with coverage and its history might know what changed during that update and thus be able to track down the issue much faster than me, I literally got into coverage about 2 days ago. Its probably just a matter of asking the right questions, but i'm not experienced enough to do so.

Steps to reproduce the issue:

  1. Create a new virtual environment with Python 3.8
  2. pip install -r requirements-dev.txt
  3. pip install path/to/the/wheel/i/provided.whl
  4. pytest --cov-config=.coveragerc --cov or coverage run -m pytest

I hope that I didn't forget anything, the problem kept me busy for quite a few hours now and I tried alot to track it down, just let me know if you need anything.

Thank you.

@Timtam Timtam added bug Something isn't working needs triage labels Feb 19, 2022
@nedbat
Copy link
Owner

nedbat commented Nov 13, 2022

Sorry I've let this sit for so long...

In the meantime I made a change in coverage.py, does that improve things? I don't have a Windows machine to test on, but I can try the other reproduction instructions if they work on Linux.

@nedbat nedbat added the question Further information is requested label Nov 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants