-
-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Automatically compute path remapping rules in "coverage combine" #1840
Labels
enhancement
New feature or request
Comments
zackw
added a commit
to MillionConcepts/pdr
that referenced
this issue
Aug 28, 2024
Instead of running the unit tests against an “editable install” of the PDR git repo, build an sdist and wheel from the git repo, then, in separate jobs that don’t ever check out the git repo, install the wheel and run the tests from the sdist against the installed wheel. This has several advantages. Most importantly, it verifies that we generate *correct* binary packages, as we were not doing until the previous commit. Testing an editable install is also subtly different in terms of things like sys.path than testing something that’s been officially installed to site-packages.[^1] Finally, this puts us in a better position to create *conda* packages (as a separate project). It would be possible to add further automation that uploads the sdist and wheel to PyPI if the commit has a release tag. The mechanism for tweaking .coveragerc for CI’s needs has also been overhauled, using a helper Python script that parses .coveragerc exactly the same way coverage.py itself does (i.e. using configparser). This should be much more reliable, both because we no longer need to make assumptions about what goes where in the file, and because the Python script can also use the coverage.py API to compute the path- remapping configuration (yes, coverage.py ought to do this itself, filed nedbat/coveragepy#1840 ). And it means we can strip all the junk that’s in .coveragerc solely for CI’s needs back out. [^1]: https://setuptools.pypa.io/en/latest/userguide/development_mode.html#limitations
zackw
added a commit
to MillionConcepts/pdr
that referenced
this issue
Aug 28, 2024
Instead of running the unit tests against an “editable install” of the PDR git repo, build an sdist and wheel from the git repo, then, in separate jobs that don’t ever check out the git repo, install the wheel and run the tests from the sdist against the installed wheel. This has several advantages. Most importantly, it verifies that we generate *correct* binary packages, as we were not doing until the previous commit. Testing an editable install is also subtly different in terms of things like sys.path than testing something that’s been officially installed to site-packages.[^1] Finally, this puts us in a better position to create *conda* packages (as a separate project). It would be possible to add further automation that uploads the sdist and wheel to PyPI if the commit has a release tag. The mechanism for tweaking .coveragerc for CI’s needs has also been overhauled, using a helper Python script that parses .coveragerc exactly the same way coverage.py itself does (i.e. using configparser). This should be much more reliable, both because we no longer need to make assumptions about what goes where in the file, and because the Python script can also use the coverage.py API to compute the path- remapping configuration (yes, coverage.py ought to do this itself, filed nedbat/coveragepy#1840 ). And it means we can strip all the junk that’s in .coveragerc solely for CI’s needs back out. [^1]: https://setuptools.pypa.io/en/latest/userguide/development_mode.html#limitations
zackw
added a commit
to MillionConcepts/pdr
that referenced
this issue
Aug 28, 2024
Instead of running the unit tests against an “editable install” of the PDR git repo, build an sdist and wheel from the git repo, then, in separate jobs that don’t ever check out the git repo, install the wheel and run the tests from the sdist against the installed wheel. This has several advantages. Most importantly, it verifies that we generate *correct* binary packages, as we were not doing until the previous commit. Testing an editable install is also subtly different in terms of things like sys.path than testing something that’s been officially installed to site-packages.[^1] Finally, this puts us in a better position to create *conda* packages (as a separate project). It would be possible to add further automation that uploads the sdist and wheel to PyPI if the commit has a release tag. The mechanism for tweaking .coveragerc for CI’s needs has also been overhauled, using a helper Python script that parses .coveragerc exactly the same way coverage.py itself does (i.e. using configparser). This should be much more reliable, both because we no longer need to make assumptions about what goes where in the file, and because the Python script can also use the coverage.py API to compute the path- remapping configuration (yes, coverage.py ought to do this itself, filed nedbat/coveragepy#1840 ). And it means we can strip all the junk that’s in .coveragerc solely for CI’s needs back out. [^1]: https://setuptools.pypa.io/en/latest/userguide/development_mode.html#limitations
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Is your feature request related to a problem? Please describe.
The
[paths]
section of a.coveragerc
is a fragile beast. By way of example, if I'm testing my Python package in Github Actions CI on MacOS, Ubuntu, and Windows using both pip and conda, and I want to merge coverage reports from all of them, then I need to have a[paths]
section like this:where
<V>
is the Python minor version (each path with<V>
in it has to be duplicated for each version of Python I'm testing with) and<PKG>
is the name of my package (there has to be a whole 'nother merge group for each package simultaneously under test).All these absolute paths are implementation details of the CI runner that could change without any warning. I shouldn't have to know them at all, let alone write them into a file that's checked into version control.
Describe the solution you'd like
Instead of having the user determine and then write down a
[paths]
stanza,coverage combine
should be able to compute all the necessary path remapping rules itself, for example like this:The
cfg
argument to this function is the ConfigParser instance for the.coveragerc
, and thedatabases
argument is a list of all the coverage databases to be combined.Describe alternatives you've considered
One alternative would be to make
relative_files
mode more aggressive; it could trim out all path components above an element ofsources
/source_pkgs
, and canonicalize path separators to/
, before writing the database in the first place. That would make the subsequent combine step not need to remap paths.Ideally, I would like to see both of the above two options implemented and maybe even on by default.
The text was updated successfully, but these errors were encountered: