Skip to content
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

Added pending_warning_type and a version to the message for deprecated #16463

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

nabobalis
Copy link
Contributor

@nabobalis nabobalis commented May 16, 2024

Fixes #8190

TODO:

  • Changelog?
  • Fix the tests

Copy link

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

  • Do the proposed changes actually accomplish desired goals?
  • Do the proposed changes follow the Astropy coding guidelines?
  • Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
  • Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
  • Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
  • Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
  • Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
  • Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
  • At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

@@ -28,6 +28,19 @@
_NotFound = object()


def _get_removal_version(since):
# Work out which version this will be removed in
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did not check if this is valid for astropy.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with Brigitta that this is orthogonal to the initial PR goal and should be left out for now.
I also wouldn't recommend attempting to predict the future in deprecation warnings; I've been bitten by it in the past where an important release got blocked by some deprecation that we promised to conclude (remove the functionality), but turned out to be more difficult than we anticipated.

Copy link

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

Copy link
Member

@bsipocz bsipocz left a comment

Choose a reason for hiding this comment

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

Looks good to me, pending the message itself is left unchanged and a changelog is added.

My preference would be to have this backported into a bugfix, so it's available for downstream usage sooner.

@@ -203,7 +224,7 @@ def deprecate(
else:
message = (
"The {func} {obj_type} is deprecated and may "
"be removed in a future version."
"be removed in a future version (minimum version {removal_version})."
Copy link
Member

Choose a reason for hiding this comment

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

I would not mix this into this PR as this breaks past behaviour when/if anyone matches with the full message. And I would rather see this feature backported, so more versions can use it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That is fair, I will remove this change.

@@ -36,6 +49,7 @@ def deprecated(
pending=False,
obj_type=None,
warning_type=AstropyDeprecationWarning,
pending_warning_type=AstropyPendingDeprecationWarning,
Copy link
Contributor

Choose a reason for hiding this comment

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

It's too late for existing arguments, but I'd suggest making any new argument in public functions keyword-only (not crucial, but helps with deprecation cycles, which this PR is all about 😄)

Suggested change
pending_warning_type=AstropyPendingDeprecationWarning,
*,
pending_warning_type=AstropyPendingDeprecationWarning,

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

@@ -28,6 +28,19 @@
_NotFound = object()


def _get_removal_version(since):
# Work out which version this will be removed in
Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with Brigitta that this is orthogonal to the initial PR goal and should be left out for now.
I also wouldn't recommend attempting to predict the future in deprecation warnings; I've been bitten by it in the past where an important release got blocked by some deprecation that we promised to conclude (remove the functionality), but turned out to be more difficult than we anticipated.

@@ -1625,7 +1625,7 @@ def _verify(self, option="warn"):
return errs


@deprecated("v6.0")
@deprecated("6.0")
Copy link
Contributor

Choose a reason for hiding this comment

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

orthogonal, but doesn't hurt

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was changed due to my adding the version in the message which needs to be able to parse these tags.

Since I will remove that change, I will be undoing this change as well.

@pllim pllim added this to the v7.0.0 milestone May 16, 2024
@pllim pllim added the API change PRs and issues that change an existing API, possibly requiring a deprecation period label May 16, 2024
@pllim
Copy link
Member

pllim commented May 16, 2024

this backported into a bugfix

But this is technically new API and I don't see the lack of this being blocker of anything downstream, so I prefer not to backport.

@bsipocz
Copy link
Member

bsipocz commented May 16, 2024

New API for a developer tool, so there isn't really much benefit in holding it back and thus delaying the ability to use it

@nabobalis nabobalis marked this pull request as ready for review May 16, 2024 18:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API change PRs and issues that change an existing API, possibly requiring a deprecation period io.fits utils
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement user-defined pending deprecation warning for deprecated decorators
4 participants