pants: The generated coveragerc seems wrong
I’ve encountered the case where the generated coveragerc looks like this:
[run]
branch = True
timid = True
[report]
exclude_lines =
def __repr__
raise NotImplementedError
[paths]
shared =
shared
.pants.d/pyprep/sources/7612f833acaeb440ee7d4249c5c2c340885c1ec7
/usr/local/google/home/tanin/projects/clusterfuzz-tools/shared
/usr/local/google/home/tanin/projects/clusterfuzz-tools/.pants.d/pyprep/sources/7612f833acaeb440ee7d4249c5c2c340885c1ec7
error =
error
.pants.d/pyprep/sources/7612f833acaeb440ee7d4249c5c2c340885c1ec7
/usr/local/google/home/tanin/projects/clusterfuzz-tools/error
/usr/local/google/home/tanin/projects/clusterfuzz-tools/.pants.d/pyprep/sources/7612f833acaeb440ee7d4249c5c2c340885c1ec7
(The content is generated from this line: https://github.com/pantsbuild/pants/blob/master/src/python/pants/backend/python/tasks2/pytest_run.py#L210)
The run command is: ./pants test.pytest --coverage=auto error:test -- -p no:logging
And here’s the BUILD:
python_tests(
name='test',
sources=rglobs('tests/*.py'),
coverage='error',
compatibility=['>=2.7','<3'],
dependencies=[
':src',
'//shared:test_libs',
'//3rdparty/python:pyfakefs',
'//3rdparty/python:mock'
]
)
:src and //shared:test_libs are regular python_librarys. :src has the module error.
This leads to the generated report below:
18:05:50 00:03 [coverage]
Name Stmts Miss Branch BrPart Cover
----------------------------------------------------------------
shared/test_libs/__init__.py 0 0 0 0 100%
shared/test_libs/helpers.py 38 38 8 0 0%
----------------------------------------------------------------
TOTAL 38 38 8 0 0%
You can see that it doesn’t include the module error. If I remove //shared:test_libs from the BUILD target, it suddenly shows the coverage from the module error.
After testing, there’s something strange around [paths]. I’m not sure.
This is Pants 1.3.0.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 18 (12 by maintainers)
Commits related to this issue
- Fix `PytestRun` to handle multiple source roots. Although an attempt was made to handle multiple source roots when mapping python source paths for `py.test` and `coverage`, there were ambiguities in ... — committed to jsirois/pants by jsirois 6 years ago
- Fix `PytestRun` to handle multiple source roots. Although an attempt was made to handle multiple source roots when mapping python source paths for `py.test` and `coverage`, there were ambiguities in ... — committed to jsirois/pants by jsirois 6 years ago
- Fix `PytestRun` to handle multiple source roots. Although an attempt was made to handle multiple source roots when mapping python source paths for `py.test` and `coverage`, there were ambiguities in ... — committed to jsirois/pants by jsirois 6 years ago
- Fix `PytestRun` to handle multiple source roots. Although an attempt was made to handle multiple source roots when mapping python source paths for `py.test` and `coverage`, there were ambiguities in ... — committed to jsirois/pants by jsirois 6 years ago
- Fix `PytestRun` to handle multiple source roots. Although an attempt was made to handle multiple source roots when mapping python source paths for `py.test` and `coverage`, there were ambiguities in ... — committed to jsirois/pants by jsirois 6 years ago
- Fix `PytestRun` to handle multiple source roots. Although an attempt was made to handle multiple source roots when mapping python source paths for `py.test` and `coverage`, there were ambiguities in ... — committed to jsirois/pants by jsirois 6 years ago
- Fix `PytestRun` to handle multiple source roots. (#5400) Although an attempt was made to handle multiple source roots when mapping python source paths for `py.test` and `coverage`, there were ambig... — committed to pantsbuild/pants by jsirois 6 years ago
- Fix `PytestRun` to handle multiple source roots. (#5400) Although an attempt was made to handle multiple source roots when mapping python source paths for `py.test` and `coverage`, there were ambigui... — committed to jsirois/pants by jsirois 6 years ago
- Fix `PytestRun` to handle multiple source roots. (#5400) (#5407) Although an attempt was made to handle multiple source roots when mapping python source paths for `py.test` and `coverage`, there wer... — committed to pantsbuild/pants by jsirois 6 years ago
- Generate a single python source chroot. This change reverts the majority of #5400 (GatherSources) and adjusts the new coverage plugin path mapping system to handle mapping a single source chroot back... — committed to jsirois/pants by jsirois 6 years ago
- Generate a single python source chroot. This change reverts the majority of #5400 (GatherSources) and adjusts the new coverage plugin path mapping system to handle mapping a single source chroot back... — committed to pantsbuild/pants by jsirois 6 years ago
- Generate a single python source chroot. This change reverts the majority of #5400 (GatherSources) and adjusts the new coverage plugin path mapping system to handle mapping a single source chroot back... — committed to jsirois/pants by jsirois 6 years ago
- Generate a single python source chroot. (#5535) This change reverts the majority of #5400 (GatherSources) and adjusts the new coverage plugin path mapping system to handle mapping a single source c... — committed to pantsbuild/pants by jsirois 6 years ago
Thanks for all the detail @tanin47! This led to a unit test that reproduces the problem. Still working through a solution, but a solution should be landing by end of week.
Tried alot of things here and the only clean way to deal with this is to model the runtime on the source setup, ie: use a separate source pex per source root involved. Giving this a shot.
Alright, just a note that the issue in the end is having multiple source roots for python code. This leads to an ambiguity in path conversion in our
coverage combinestep which leads to an arbitrary source root being picked bycoverage. Whencoveragethen looks for files not in that source root, coverage is not found. Still poking about for solutions.But you may be able to force a different coverage version by sneaking it in to the requirements via ----unittest2-requirements (I’m assuming you’re using a python version that has a current unittest already), e.g.:
–pytest-cov-requirements=“pytest-cov>=2.4,<2.5” –unittest2-requirements=“coverage>=1.0,<2.0”
or:
[pytest] requirements: “pytest>=3.0.7,<4.0” unittest2_requirements: “coverage>=1.0,<2.0”
On Thu, Jan 18, 2018 at 4:13 PM, Benjy Weinberger benjyw@gmail.com wrote:
From the command-line:
–pytest-requirements=“pytest>=3.0.7,<4.0” –pytest-cov-requirements=“pytest-cov>=2.4,<2.5”
Or in pants.ini:
[pytest] requirements: “pytest>=3.0.7,<4.0” cov_requirements: “pytest-cov>=2.4,<2.5”
Note that AFAIK we don’t set the version of coverage explicitly - we let pytest-cov determine the version(s) it’s compatible with.
On Thu, Jan 18, 2018 at 1:18 PM, Tanin Na Nakorn notifications@github.com wrote: