Skip to content

ENH: Permit external packages to deprecate interfaces #2028

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

Merged
merged 3 commits into from
May 24, 2017

Conversation

effigies
Copy link
Member

External projects, such as poldracklab/niworkflows, may maintain a set of interfaces, that over time require deprecating portions of their input and output specs. At present, the deprecation machinery is intrinsically tied to nipype's version number.

This PR adds a package_version attribute to each interface, which defaults to nipype's, but allows other packages easily to add their own versioning information to specs with a deprecation schedule.

@codecov-io
Copy link

Codecov Report

Merging #2028 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master   #2028      +/-   ##
=========================================
+ Coverage    72.2%   72.2%   +<.01%     
=========================================
  Files        1132    1132              
  Lines       57023   57024       +1     
  Branches     8165    8165              
=========================================
+ Hits        41173   41176       +3     
+ Misses      14566   14564       -2     
  Partials     1284    1284
Flag Coverage Δ
#smoketests 72.2% <100%> (ø) ⬆️
#unittests 69.8% <100%> (ø) ⬆️
Impacted Files Coverage Δ
nipype/interfaces/base.py 83.97% <100%> (+0.19%) ⬆️

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 f92a333...db630a6. Read the comment docs.

@codecov-io
Copy link

codecov-io commented May 18, 2017

Codecov Report

Merging #2028 into master will increase coverage by <.01%.
The diff coverage is 80%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2028      +/-   ##
==========================================
+ Coverage   72.17%   72.17%   +<.01%     
==========================================
  Files        1134     1134              
  Lines       57096    57098       +2     
  Branches     8179     8179              
==========================================
+ Hits        41208    41210       +2     
  Misses      14602    14602              
  Partials     1286     1286
Flag Coverage Δ
#smoketests 72.17% <80%> (ø) ⬆️
#unittests 69.78% <80%> (ø) ⬆️
Impacted Files Coverage Δ
nipype/info.py 84.37% <0%> (ø) ⬆️
nipype/interfaces/base.py 83.8% <100%> (+0.02%) ⬆️

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 c4543dc...f0d7070. Read the comment docs.

@effigies
Copy link
Member Author

I'm moving to packaging.version.Version instead of LooseVersion for spec deprecations. It's PEP440-compliant, which is the standard that pip uses to resolve versions, while LooseVersion is just a pain wrt pre-release version strings.

This did require me to switch the gitversion scheme to 1.0.0-dev+githash as opposed to 1.0.0-githash.dev. Will this cause problems? I assume it's mostly for readability; neither is more cmpable than the other.

Obviously it isn't appropriate for things like min_ver, where we have no control over external versioning schemes.

cc @satra @chrisfilo

@@ -31,6 +31,7 @@
from warnings import warn
import simplejson as json
from dateutil.parser import parse as parseutc
from packaging.version import Version

from .. import config, logging, LooseVersion, __version__
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove LooseVersion from everywhere?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's used for versioning on external programs, e.g. FSVersion < 6.0 or FSLVersion > 507. Since these don't follow PEP440, I intended to leave them as they are.

@@ -141,7 +141,8 @@ def get_nipype_gitversion():
'configparser',
'pytest>=%s' % PYTEST_MIN_VERSION,
'mock',
'pydotplus'
'pydotplus',
'packaging',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

packing should be added to requirements.txt and rtd_requirements as well?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think, this would also need to be added to SETUP_REQUIRES. you can check by trying to install nipype in a clean environment using python setup.py install.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Building the docker image (I never figured out how to do virtualenvs) from scratch. Is that an equivalent check?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can do this inside a basic continuumio/miniconda docker instance - think of that as a virtualenv.

docker run -it --rm -v /path/to/nipype:/nipype-src continuumio/miniconda bash
> cd /nipype-src
> python setup.py bdist_wheel

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and more generally download and install miniconda and then do: conda create -n envname python=2/3 for creating virtual envs

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Builds and installs without issue. (Had to apt-get install build-essential, conda install scipy, lxml and dependencies, but otherwise no problems.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so that latter are runtime dependencies not setup dependencies. there is difference between setup requires and run/test requires. setup requires are things that the setup.py file imports.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. I don't think packaging is required by that. Running python setup.py bdist_wheel worked fine. I then also ran python setup.py install which required the other dependencies.

Sorry if I'm missing something.

@satra
Copy link
Member

satra commented May 18, 2017

can this wait for the next release? or should it be included now?

@effigies
Copy link
Member Author

It can wait.

@effigies
Copy link
Member Author

@satra This is ready for another look, now the release is out.

@effigies effigies force-pushed the enh/external_deprecation branch from 42d1f1e to 2a17697 Compare May 22, 2017 14:58
@satra
Copy link
Member

satra commented May 22, 2017

@effigies - could you please merge with master?

@effigies
Copy link
Member Author

It's rebased off master.

@satra
Copy link
Member

satra commented May 22, 2017

@effigies - that's weird, i haven't seen that error in all the builds i have run in the last few days? also i don't see a commit message above that merges off of current master. (circle doesn't merge with master when a PR is run).

@effigies
Copy link
Member Author

Yeah, I noticed that. I'm guessing the issue is caused by removing the updated version of docker, but why it's waited until now to exhibit this failure is unknown.

First commit: b700261
Parent: ff02ed0

Sorry if I'm being dense, but I'm not sure what you're expecting to see.

@effigies
Copy link
Member Author

So it seems like restoring docker loses caching...

@satra
Copy link
Member

satra commented May 23, 2017

@effigies - since we are testing this out, could you please now remove those two lines?

@effigies effigies force-pushed the enh/external_deprecation branch from b068c3e to 2a17697 Compare May 23, 2017 22:03
@effigies
Copy link
Member Author

effigies commented May 23, 2017

Removed that commit. Circle tests are re-running.

@effigies effigies force-pushed the enh/external_deprecation branch from 039362c to f0d7070 Compare May 24, 2017 10:27
@effigies
Copy link
Member Author

Passing. Doesn't look like we benefited from caching, but the Circle caching mechanism is opaque to me. Perhaps it takes a couple attempts to get something usable to a future build.

@satra satra merged commit c13f967 into nipy:master May 24, 2017
@effigies effigies deleted the enh/external_deprecation branch May 24, 2017 20:18
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.

3 participants