Fix paths in .coverage file in Python 3 #4822
Conversation
…e coverage reporting does not work in Python 3. This will not work in Python 3 for packages that still use 2to3, but this never worked anyway since the temporary files got deleted before.
|
I'm also enabling coverage testing on Python 3 in the |
astrofrog
force-pushed
the
fix-coverage-py3
branch
from
0dad9ec to
52731e9
Compare
|
@astropy/astropy-core-maintainers - this is now ready for review. However, the Travis build on which I enabled Python 3 coverage testing goes from 8 minutes to 24 minutes. I've opened an issue to remind us to investigate why running with coverage testing is so much slower on Python 3 (#4826). If people are opposed to the increase in testing time, I can disable the Python 3 coverage testing again? (at least we know it works now) |
|
@astrofrog - great that it now works well on python3! I think we should definitely opt for either python2 or python3 for coverage, not do both. My sense would be to stick to python2 until we figure out why python3 takes so much longer, i.e., I would suggest not to make the change to |
|
@mhvk - sounds good - I just wanted to make the change as part of this PR to make sure it works, but happy to remove it. |
|
Hmm. Does it also take 24 minutes locally? If so, maybe profiling can pinpoint where it is so slow. |
.travis.yml
Outdated
| CFLAGS='-ftest-coverage -fprofile-arcs -fno-inline-functions -O0' | ||
| - os: linux | ||
| env: PYTHON_VERSION=3.4 SETUP_CMD='test' | ||
| env: PYTHON_VERSION=3.4 SETUP_CMD='test --coverage' |
There was a problem hiding this comment.
I just left it as-is for now, I think that should be changed in a separate PR.
There was a problem hiding this comment.
I am also wondering if it is also slow in Python 3.5 or just 3.4.
There was a problem hiding this comment.
Ah I see what you mean - it's slow on Python 3.5 too (I see it locally)
|
@pllim - yes, it also takes a while locally, for me at least. I'm not sure on the best way to profile the tests because it seems to be an issue that occurs only when the coverage testing is working, so it's not just about profiling individual astropy functions or operations. I don't really have time to look into it now, but we should discuss it in #4826 |
astrofrog
force-pushed
the
fix-coverage-py3
branch
from
52731e9 to
1776889
Compare
…thon 3 we run into issues, since we are modifying the dictionary on-the-fly, and this causes some of the keys to not be iterated over. For Python 2, this means taking an unnecessary copy, but this is not a performance-critical loop.
|
I've now removed the commit that changed the |
|
@astrofrog - OK, let's move over to trying to figure out why coverage is so much slower on python3. Merging this aspect so that testing can be done on master! |
Fix paths in .coverage file in Python 3
Fix paths in .coverage file in Python 3
Fix paths in .coverage file in Python 3
3 participants
Fixes paths in .coverage file in Python 3 like we do in Python 2, otherwise coverage reporting to e.g. coveralls does not work in Python 3. This will not work in Python 3 for packages that still use 2to3, but this never worked anyway since the temporary files got deleted before.
This should fix astropy/package-template#151