Repository navigation
Moving coverage travis build from python2.7 to python3.5 - #5401
Conversation
|
-0.04% does not look terribly massive. When I click on "coverage changed" tab in the report, seems like only |
|
As for the timing, comparing with the latest master build's coverage report: And this PR: Not super slow but still slower. No increase in performance. I wonder if it is due to all the |
|
I remember that with python2 tests are run twice, once with unicode literals, once without, so that a decrease is expected (note the substantially smaller number of tests that were run in @pllim's example above). Overall, my sense is to go for it now... |
|
@pllim - There is some daily fluctuation in travis run times, so I think it's closer to the true difference to compare two coverage builds from the same travis run, e.g. using my testing branch: https://travis-ci.org/bsipocz/astropy/jobs/166497098#L2550 |
|
@pllim - I think you're right, and I was the one who misread the report (I still think it's confusing). It's seems to be one line for almost every file, maybe there're the |
|
@bsipocz , the two builds you linked to seem to both used Python 3.5... |
|
I think the first one is python 2.7: https://travis-ci.org/bsipocz/astropy/jobs/166497098#L2109 |
|
@bsipocz , yes, you're right! I was confused by |
|
@pllim - no problem, I saw more travis log than my fair share to spot it :) The first exports are coming from the global settings, then they get overridden with the locals of the individual builds. I agree that it can be very misleading. |
|
OK, I'll merge this, as I think it is good to be on python3 altogether, and it seems that there is no real downside left. Thanks, @bsipocz! |
As it was discussed in #4826 the slowness of the python3 coverage run should be solved when using a newer version, so probably we can move to python3 with this PR.