Skip to content

MRG: add routine to deprecate with from/to versions #479

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 8 commits into from
Aug 15, 2016

Conversation

matthew-brett
Copy link
Member

Add deprecation routine that allows you to specify at which version
deprecation began, and at which version deprecation will raise an error.

@coveralls
Copy link

coveralls commented Aug 10, 2016

Coverage Status

Coverage decreased (-0.002%) to 96.241% when pulling b527e25 on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

@codecov-io
Copy link

codecov-io commented Aug 10, 2016

Current coverage is 94.42% (diff: 100%)

Merging #479 into master will increase coverage by 0.15%

@@             master       #479   diff @@
==========================================
  Files           161        164     +3   
  Lines         21321      21597   +276   
  Methods           0          0          
  Messages          0          0          
  Branches       2284       2295    +11   
==========================================
+ Hits          20100      20394   +294   
+ Misses          801        783    -18   
  Partials        420        420          

Powered by Codecov. Last update e37cb5d...f82e217

@functools.wraps(func)
def deprecated_func(*args, **kwargs):
if expired:
raise expired_class(message)
Copy link
Member

Choose a reason for hiding this comment

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

Isn't better place for this check within outer decorator itself? So you don't wait for it to be used but indicate to developers/yourself that it is time to really remove it completely?

Copy link
Member Author

@matthew-brett matthew-brett Aug 10, 2016

Choose a reason for hiding this comment

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

My worry is that someone (presumably me) will forget to remove them in time, and some code will get out into the wild in that state. In that case, then the error will only occur if they try and use the functions that they shouldn't be using, instead of completely breaking the module import.

I think all these functions have their deprecations checked, so they should generate a test error when they expire.

Copy link
Member

Choose a reason for hiding this comment

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

That was kinda the point - now codebase has methods which should have been gone awhile back. Since bookings is using them, nothing is removed. As long as you run tests on 'to be released' version (easy to do by just pushing a PR with to be released changes), you will know that those functions must be removed. I guess I will also use it eg in duecredit where releases are done from successfully built tagged pushes to github. If build/release would fail - I would know that I had to remove some

Copy link
Member

Choose a reason for hiding this comment

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

But overall out is up to you of cause! Just kinda defeats the original cause/purpose of my whining ;-)

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 - but don't forget - tests will fail as soon as the version goes over the version where deprecation ends. So, even if I release a version where I forgot to remove the function, as soon as I start the next development version, on the commit after the release, the tests will fail. That way I get to see that I forgot, without giving the user code which won't import.

Copy link
Member

Choose a reason for hiding this comment

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

Ok. That is if you do have a test for every deprecated function. I didn't look at coverage of those functions, but overall coverage is not 100% (no pun intended, coverage is exemplary high) so some might be sneaking in.
But that is again is all fine with me ;-)

@yarikoptic
Copy link
Member

I guess note it is time also to annotate those which issue deprecation warning already. Paired within this PR would provide usecase testing ;-)

@matthew-brett
Copy link
Member Author

Just doing that now - should be done in an hour or so.

@coveralls
Copy link

coveralls commented Aug 10, 2016

Coverage Status

Coverage increased (+0.02%) to 96.263% when pulling b24e459 on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

@coveralls
Copy link

coveralls commented Aug 10, 2016

Coverage Status

Coverage increased (+0.04%) to 96.28% when pulling 385e68b on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

@coveralls
Copy link

coveralls commented Aug 10, 2016

Coverage Status

Coverage increased (+0.05%) to 96.289% when pulling dd14a0b on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

@matthew-brett
Copy link
Member Author

OK - I believe all deprecation warnings are covered by the tests, and are versioned.

@coveralls
Copy link

coveralls commented Aug 10, 2016

Coverage Status

Coverage increased (+0.1%) to 96.351% when pulling 00d4e18 on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

@coveralls
Copy link

coveralls commented Aug 10, 2016

Coverage Status

Coverage increased (+0.1%) to 96.351% when pulling 39fbd6b on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

@coveralls
Copy link

coveralls commented Aug 10, 2016

Coverage Status

Coverage increased (+0.1%) to 96.351% when pulling 26e1ab4 on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

@deprecate_with_version('get_header method is deprecated.\n'
'Please use the ``img.header`` property '
'instead.',
'2.1', '4.0')
Copy link
Member

Choose a reason for hiding this comment

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

This was at least deprecated in the docs at 2.0.0. Is this meant to indicate the first release a warning was raised?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, I was assuming that no-one was reading the docs, and so dated the deprecation from the first warning.

@effigies
Copy link
Member

Should be deprecating SpatialImage.get_affine.

@effigies
Copy link
Member

Weird: I'm seeint EcatImage overrode SpatialImage.from_filespec, so it was not raising deprecation warnings. Probably should be now?

Maybe it should be removed on a shorter time-scale than 4.0, though, since it's pretty unlikely people would be using that at this point.

@deprecate_with_version('get_shape method is deprecated.\n'
'Please use the ``img.shape`` property '
'instead.',
'1.2', '3.0')
def get_shape(self):
""" Return shape for image

This function deprecated; please use the ``shape`` property instead
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 deprecate_with_version adds to the docstring?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point.

@matthew-brett
Copy link
Member Author

Good catch with from_filespec in ECAT. I am sure few people are using it, but I'd prefer to be gentle in removing, there isn't much cost to keeping it another version.

@deprecate_with_version('get_header method is deprecated.\n'
'Please use the ``img.header`` property '
'instead.',
'2.1', '4.0')
def get_header(self):
""" Get header from image

Please use the `header` property instead of `get_header`; we will
deprecate this method in future versions of nibabel.
Copy link
Member

Choose a reason for hiding this comment

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

Another docstring warning.

@coveralls
Copy link

coveralls commented Aug 11, 2016

Coverage Status

Coverage increased (+0.1%) to 96.358% when pulling 51e12ae on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

@deprecate_with_version('read_img_data deprecated.'
'Please use ``img.dataobj.get_unscaled()`` instead.'
'2.0.1',
'4.0')
def read_img_data(img, prefer='scaled'):
Copy link
Member

Choose a reason for hiding this comment

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

This function also has a docstring deprecation notice.

@coveralls
Copy link

coveralls commented Aug 12, 2016

Coverage Status

Coverage increased (+0.1%) to 96.374% when pulling b2512e9 on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

@matthew-brett matthew-brett changed the title WIP: add routine to deprecate with from/to versions MRG: add routine to deprecate with from/to versions Aug 12, 2016
@matthew-brett
Copy link
Member Author

I refactored the deprecation warning machinery - now in nibabel/deprecator.py - any chance of another quick review from the assembly?

@coveralls
Copy link

coveralls commented Aug 12, 2016

Coverage Status

Coverage increased (+0.1%) to 96.374% when pulling 638a6ad on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

pass


deprecate_with_version = Deprecator(cmp_pkg_version)
Copy link
Member

Choose a reason for hiding this comment

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

Did you want the warning class to be VisibleDeprecationWarning?

Copy link
Member Author

Choose a reason for hiding this comment

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

I wasn't planning on it. Numpy uses these for deprecations where the user is probably making a coding error. We could promote all our deprecations, but that might be noisy.

Copy link
Member

Choose a reason for hiding this comment

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

Gotcha. Just didn't see where it was being used. I'll have a more thorough review of the whole thing, now I'm awake again.

@effigies
Copy link
Member

Review complete.

Add function to compare our package version to others.  We'll use this
to see whether the deprecations have expired.
Add deprecation class and function that allows you to specify at which
version deprecation began, and at which version deprecation will raise
an error.
Check that dev version doesn't trigger error from deprecation decorator.
Replace `np.deprecate_with_doc` with `deprecate_with_version`.

There are other deprecations around the code-base that could be
signalled with this decorator.
It was already broken, and has been deprecated since version 1.0.
Specify version at which DeprecationWarning was first raised, and
planned version for removal.

Add tests for some deprecations that were not being tested.
Thanks to Chris M for reminding me.
ECAT overriding deprecated (now removed) from_filespec method in
SpatialImages.  Deprecate pending removal.
@matthew-brett
Copy link
Member Author

Thanks for the review - I've extended the docstrings / comments a bit to make it clearer what I was trying to do.

@coveralls
Copy link

coveralls commented Aug 12, 2016

Coverage Status

Coverage increased (+0.1%) to 96.374% when pulling f82e217 on matthew-brett:fancy-deprecations into e37cb5d on nipy:master.

@effigies
Copy link
Member

Got it. LGTM.

@matthew-brett matthew-brett merged commit 20cc0fc into nipy:master Aug 15, 2016
@matthew-brett
Copy link
Member Author

Thanks a lot for the review.

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.

5 participants