MNT: Drop Python 2 support #2654
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2654 +/- ##
==========================================
- Coverage 68.14% 67.83% -0.32%
==========================================
Files 297 295 -2
Lines 39810 39255 -555
Branches 5218 5171 -47
==========================================
- Hits 27130 26627 -503
+ Misses 11968 11919 -49
+ Partials 712 709 -3
Continue to review full report at Codecov.
|
|
@effigies - since 2.0 is python 3 only, a lot of current code (e.g., use of future) can be removed/simplified. but this will also make bringing fixes in from 1.0 require some changes. we should perhaps not merge master, but cherry pick commits from master into a new PR against dev/2.0 (where a clean merge is possible that would be fine with me). another thought is whether to break off the engine, interfaces into their own separate projects. we can start with the engine, since i think that is the most self-contained component. |
| fi | ||
| - persist_to_workspace: | ||
| root: /tmp | ||
| paths: | ||
| - docker | ||
|
|
||
| test_py3_fmri_fsl_spm: | ||
| test_fmri_fsl_spm: |
There was a problem hiding this comment.
should we consider breaking off the workflows and workflow tests to niflows, before we break off 2.0?
There was a problem hiding this comment.
i'm also fine with making all the breaks with 2.0.
There was a problem hiding this comment.
I'm happy to start moving things to niflows. Have we figured out a working plan for that? Maybe could do a chat sometime this week to iron out a rough plan?
.circleci/config.yml
Outdated
| @@ -339,21 +316,15 @@ jobs: | |||
| - run: | |||
| name: Check pypi preconditions | |||
| command: | | |||
| pyenv local 3.5.2 | |||
| pip install --upgrade twine future wheel readme_renderer setuptools | |||
|
@effigies - current changes look good to me. |
The reason I like merging master is that it marks changes as already included, which makes the next merge off master simpler. I am doing a |
|
And thanks for the review. I'll make the |
|
@effigies - merging master is fine, as long as we are curating. |
RF: Drop various remaining compatibilities for Python < 3.5
Reviewed by CJM
|
I would be happy to drop official Py2 support before 2.0. This branch is almost entirely that, and...
My feeling is that if it's mostly done and would make 1.x maintenance easier overall (to whatever extent that will need to keep happening), it's worth doing. Which purging Python 2 is. Separating out interface packages isn't really, so I'd lean toward making that part of 2.0. |
|
@satra I interpreted "nipype |
|
@effigies - let's say 1.4 will be released mid december, with master branch moving from supporting both to pure py3 starting after the next release 1.3 (which is scheduled soon, correct?) we should make a release branch for any specific hot fixes that should go in to a 1.3.x release |
|
@satra Sounds good to me. Including that, this would be the current schedule
The 1.3.1 would be contingent on there being bugs to fix, although we rarely go a month without... |
effigies
changed the title
|
Do you need a review on this? |
|
Not really, though you're welcome to. We'll do another sync after the final 1.3.0 release, and then we can merge in, so it might make more sense to wait on that. |
|
@satra Can you verify the latest merge commit? If that's good, this should be good to merge. |
|
looks good. |
Summary
This PR is a notification that I've started a
dev/2.0branch, and perhaps a place to centralize discussion.It's already basically unreadable, due to the changes to
make specs, so if anybody wants to review, I'd recommend doing it commit-by-commit. Once we decide that this is okay, we then direct any further work to PRs against this branch (e.g. #2629 and #2648).I'd also suggest periodically opening a PR to merge
masterintodev/2.0, perhaps at release time, so that 1.x improvements make it in.List of changes proposed in this PR (pull-request)
interfaces.ants.legacymake specsAcknowledgment