MNT: Drop Python 3.6, test setuptools builds, pip installations #593
Conversation
effigies
force-pushed
the
ci/drop_setuptools_tests
branch
from
8d8d940 to
e6006f5
Compare
|
Since Numpy is dropping Python 3.6, should we follow suit and make our lives easier? (BTW, the failed test is unrelated to these changes, obviously - I'm getting a similar error on sdcflows proper) |
|
Yup, I'm okay with us following numpy's lead in NEP29. For reference NiBabel and Nipype are on NEP29 + 1 year, and PyBIDS is just going with Python EOL at this point. But as mostly user-facing tools with containerized installations, there's no strong need for nipreps to outlast numpy. |
effigies
changed the title
|
The failing test is because scikit-image. Docker build log: Testing an update on nipreps/sdcflows#158 |
|
Yeah, let's update the numpy/scipy/scikit-learn dependencies. Should I use the versions you're using over there? |
I think so. I'm trying to find the least annoying way of installing scikit-image. It seems that pip will be the fastest option (conda-forge also attempts to change many package's versions/builds). I have also bumped setuptools and pip inside the Dockerimage - we probably want to unpin setuptools and use the latest at the time is cleaned up. |
|
I'm also thinking that we could be more flexible with pinning and do not force patch releases. That should make the installation less breakable (assuming packages do not break dependency tables on patch release changes, which seems fairly safe to assume). Then, when releasing, we could clean up the conda layer to force a fresh installation (or have a cron job do this). |
|
Okay, done on SDCFlows. Have the dependency be resolved by pip was the best option. Pinned: |
|
Do you want to include that in this PR? |
Codecov Report
@@ Coverage Diff @@
## master #593 +/- ##
==========================================
- Coverage 47.59% 46.44% -1.15%
==========================================
Files 44 44
Lines 5356 5352 -4
Branches 785 781 -4
==========================================
- Hits 2549 2486 -63
- Misses 2714 2782 +68
+ Partials 93 84 -9
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
As noted in other discussions, setuptools is aiming to be an installation backend, not an installer, and has no plans to implement various installation PEPs, such as respecting the
PythonRequiresmetadata exposed by PyPI.Therefore I think the recommended installation method needs to be pip. Since we distribute sdists and wheels, we should continue to test those, and those are built with
setuptoolsandwheel, but we do not need to test against old versions.We may want to test against old versions of
pipagain, but I think after a year or two of usingpyproject.toml, we're pretty comfortable that pip can fetch installation dependencies as needed for this project and its dependencies.