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

Follow requirement to allow finalizers to run #108

Closed

Conversation

anishathalye
Copy link
Member

Tests on some platforms and Python versions (Python 3.7, 3.8, and 3.9 on Ubuntu and macOS) were hanging with coverage==6.3.

See nedbat/coveragepy#1310 and nedbat/coveragepy#1312 for some discussion about this issue. Some people have pinned coverage==6.2 as a temporary workaround. As discussed in #1312, coverage fixes this issue in 00da68ef1a0b4d43c003babae0cb8f91beaf06d2 by only setting signal handlers from the main thread; I confirmed that using the latest commit of coverage (aad5ece47bf12bceff4296516f23171a06b34bb5) fixes the issue of tests hanging without any modification to our code.

However, according to the pytest-cov documentation (https://pytest-cov.readthedocs.io/en/latest/subprocess-support.html#if-you-use-multiprocessing-pool), when using multiprocessing.Pool, we are supposed to ensure that join() is called on the pool, rather than terminate(). Following this requirement makes the tests work with coverage==6.3 as well.

Tests on some platforms and Python versions (Python 3.7, 3.8, and 3.9 on
Ubuntu and macOS) were hanging with coverage==6.3.

See nedbat/coveragepy#1310 and
nedbat/coveragepy#1312 for some discussion
about this issue. Some people have pinned coverage==6.2 as a temporary
workaround. As discussed in #1312, coverage fixes this issue in
00da68ef1a0b4d43c003babae0cb8f91beaf06d2 by only setting signal handlers
from the main thread; I confirmed that using the latest commit of
coverage (aad5ece47bf12bceff4296516f23171a06b34bb5) fixes the issue of
tests hanging without any modification to our code.

However, according to the pytest-cov documentation
(https://pytest-cov.readthedocs.io/en/latest/subprocess-support.html#if-you-use-multiprocessing-pool),
when using `multiprocessing.Pool`, we are supposed to ensure that
`join()` is called on the pool, rather than `terminate()`. Following
this requirement makes the tests work with coverage==6.3 as well.
@codecov-commenter
Copy link

codecov-commenter commented Feb 1, 2022

Codecov Report

Merging #108 (35fa3db) into master (3fb5024) will increase coverage by 0.09%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #108      +/-   ##
==========================================
+ Coverage   86.50%   86.59%   +0.09%     
==========================================
  Files          12       12              
  Lines         956      955       -1     
  Branches      163      162       -1     
==========================================
  Hits          827      827              
+ Misses        115      114       -1     
  Partials       14       14              
Impacted Files Coverage Δ
cleanlab/pruning.py 91.27% <100.00%> (+0.60%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3fb5024...35fa3db. Read the comment docs.

@jwmueller
Copy link
Member

lgtm, but will defer final review to @cgnorthcutt

It's a bit weird that we need to change our source code to accommodate the coverage tests though, hopefully that doesn't happen again going forward...

@anishathalye anishathalye mentioned this pull request Feb 2, 2022
@anishathalye
Copy link
Member Author

If we don't care about coverage on Windows, we don't need this. coverage==6.3 was trying to fix this limitation of not requiring a join() and saving coverage data on terminate() as well (in nedbat/coveragepy@dd575ee), but it didn't get it quite right, hence CI breaking. nedbat/coveragepy@00da68e fixes the issue, so using this version of coverage (not yet released on PyPI) won't require code changes on our end, but I think it won't save coverage in forked threads on Windows? (But it wasn't doing this before anyways?)

Maybe that's a fine trade-off, and we can ignore this PR (and pin an old version of coverage until a new version is released). #109

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.

None yet

3 participants