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

[CI] Improve coverage config #3050

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

abravalheri
Copy link
Contributor

Summary of changes

Currently there is a lot of noise and problems when running coverage in the CI.
This is an attempt to improve the configuration and clean the coverage output.

Closes

Pull Request Checklist

.coveragerc Outdated
omit =
# leading `*/` for pytest-dev/pytest-cov#456
*/.tox/*
*/_vendor/*
*/_distutils/*
Copy link
Contributor Author

@abravalheri abravalheri Jan 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently most of _distutils shows up as 0 hit, so it seems to me that omitting is the best, but I might be wrong...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My guess is it shows up as not being hit because of the name mismatch (setuptools._distutils versus distutils). I do try to avoid these snowflake configurations, but I also recognize they may be needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abravalheri I wonder if just Codecov needs to be configured not to take it into account vs the underlying coveragepy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @jaraco and @webknjaz for the review.

I wonder if just Codecov needs to be configured not to take it into account vs the underlying coveragepy.

My approach would be trying to solve things with coveragepy first, because on my personal machine I rely on the terminal report which is very useful. Any Codecov change would just be useful after a PR is made...

@abravalheri abravalheri force-pushed the improve-coverage-config branch 2 times, most recently from 84c2a2c to b5fd0c1 Compare January 25, 2022 15:44
.coveragerc Outdated
pkg_resources/
*/site-packages/pkg_resources/
*/pip-install-*/setuptools_*/pkg_resources/
*/tmp*/pkg_resources
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The combination of the project layout and the kinds of tests we run is rather unique (2 top-level packages, in-tree tests and flat-layout, tests using pip-run), which require a bespoke path configuration...

For most of packages using src-layout, the following configuration is enough:

[paths]
source =
	src/
	*/site-packages/

The equivalent for flat-layout is:

[paths]
source =
	../  # seems to be resolved against the `.coveragerc` file path, not the current folder
	*/site-packages/

... but coverage does not allow specifying wildcards as the last segment in [paths], therefore we need an entry for each setuptools and pkg_resources.
*/pip-install-* paths seem to be created by pip-run and */tmp* paths are created when installing into directories created with the tempfile module.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes me sad. I've noticed recently (3-6 months ago) in my other projects that they too have started reporting coverage (or errors measuring coverage) on files outside the source tree. Making this change here implies adding a similar but unique change to every other project.

What I'd really like to see is some automation in pytest-cov or coverage to automatically detect the files in the local repo and use those files to determine where to measure coverage.

I've filed jaraco/skeleton#56 to track the broader issue. Can we start by investigating the issue in a simpler project like jaraco/tempora and solve other meta issues that affect other projects in the skeleton before applying solutions that are setuptools-specific and add more maintenance burden to this project?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about reporting this to @nedbat as an upstream FR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for the comment guys.

I spent quite a lot of time the past week trying to investigate on how to make this configuration as generic as possible, experimenting with several projects, but unfortunately I could not find that "one configuration to rule them all".

There seem to be a lot of factors that can influence the report, for example:

  • flat vs src-layout
  • In-package tests vs separated tests folder
  • Usage of develop=True in tox.ini
  • Usage of isolated_build=True in tox.ini
  • Usage of changedir in tox.ini
  • Usage of --installpkg flag with tox
  • coverage vs pytest-cov

Some things I have noticed:

  • When using a flat layout and develop=True, omitting the [paths] seems to work OK. However that does not work well with src-layout...
  • When I was experimenting with tempora, for some reason, using --cov alone seems to cause coverage warnings, while using --cov tempora results in a cleaner output, regardless of the presence of [run] source = tempora in .coveragerc.

So far the best approach I did manage to find (less noisy) is to use [run] source = ..., [paths] and still pass in the command line --cov=PACKAGE_NAME instead of just --cov. That seems to work for a broad combination of the factors I described previously, but it does need the name of the package under test to be hardcoded in some configuration files...

@abravalheri abravalheri marked this pull request as ready for review January 26, 2022 10:17
@abravalheri abravalheri changed the title Improve coverage config [CI] Improve coverage config Jan 26, 2022
.coveragerc Outdated Show resolved Hide resolved
@abravalheri
Copy link
Contributor Author

Thank you very much @jaraco and @webknjaz for the kind reviews. I tried to address some straight-forward changes as proposed, but others are a bit more complicated.

In the latest commits, I tried to simplify the configuration by removing the [paths] section I had previously added. In general this section is important for testing installed packages, but since setuptools is tested via usedevelop=True, it should not impact too much (the reason why I added it in the first place was because I was doing some experiments to remove usedevelop=True).

Unfortunately I did not find a way of not specifying explicitly the package name in the configuration and still obtain clean output (without explicitly specifying the package names there is a lot of warnings and noise in the output).

Copy link
Member

@webknjaz webknjaz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it's ready now...


[report]
show_missing = True
skip_covered = True
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This configuration is more appropriate for large projects such as setuptools, as indicated in #3050 (comment)

omit =
# leading `*/` for pytest-dev/pytest-cov#456
*/.tox/*
*/_vendor/*
*/_distutils/tests/*
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

setuptools/_distutils/tests are not being run in the setuptools CI. So I think it make sense to omit them.

@agronholm
Copy link
Contributor

Shouldn't this configuration be merged into pyproject.toml?

@jaraco
Copy link
Member

jaraco commented Mar 26, 2022

Shouldn't this configuration be merged into pyproject.toml?

I haven't yet had a chance to write a blog post about it. Combining all the config into a single file is problemmatic because it conflates concerns and increases the possibility of conflicts as projects share config and have divergent concerns. Let's keep the concerns separated for now. If you think the files should be combined, please file the report at jaraco/skeleton and I can discuss it further there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants