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

Move cbook.deprecation to _api.deprecation #18657

Merged
merged 6 commits into from
Oct 26, 2020

Conversation

timhoffm
Copy link
Member

@timhoffm timhoffm commented Oct 4, 2020

PR Summary

This is the first step of removing the deprecation functions from the public interface.

There's still a lot to do in follow-up:

  • Re-import the submodule contents in _api (as we are currently doing in cbook). This then allows use to write code like _api.warn_deprecated or @_api.delete_parameter()
  • Change all interal usage to _api.* calls
  • Deprecate the functions made public via cbook.

The additional steps will generate a lot of trivial internal changes and are best reviewed as a separate PR, which I will prepare after this one is in.

@timhoffm timhoffm added this to the v3.4.0 milestone Oct 4, 2020
@ianhi
Copy link
Contributor

ianhi commented Oct 5, 2020

Is much of cbook going to disappear into private api? I think lots of stuff in there is helpful for 3rd party packages. For example, I'm sad to see the deprecation functions go as I've used warn_deprecated (https://github.com/ianhi/mpl-interactions/blob/0.6.1/mpl_interactions/pyplot.py#L6). I tried for a bit to figure out the best way to make deprecation warnings, but in the end it was far easier to piggyback off the work already done in matplotlib. This allowed me to avoid reinventing anything and to avoid picking up a non-matplotlib dependency.

A nice alternative for 3rd party packages would be to include simple advice on how to make warnings to the imagined page giving advice on making a 3rd party package #18496?

@jklymak
Copy link
Member

jklymak commented Oct 5, 2020

@ianhi I think the idea is that its private so we can change at our convenience w/o a huge deprecation dance. If another library wanted to vendor the machinery, that would be great, but we don't want to be in the position of publicly maintaining it.

@timhoffm
Copy link
Member Author

timhoffm commented Oct 5, 2020

@ianhi I understand your motivation. However, this is internal functionality to make matplotlib API evolution easier to manage. It's not part of the functionality, we commit to provide to users or downstream libraries.

While convenient for downstream libraries, having this is a burden on the matplotlib developer side. First, these functions are only designed to work within matplotlib. We don't claim or aspire that they will still work in other contexts. Second, a public API is a fixed interface, that we cannot easily change. This reduces our own capability of further adapting it to our needs.

Even though not recommended you could still import from the private API. But we're not going to guarantee the API, which is basically the whole point of making this private. Possibly the best way for you is to vendor the relevant code part.

@dopplershift
Copy link
Contributor

For MetPy we vendored the deprecation functionality. I'd suggest any other projects relying on matplotlib's deprecation code to do that or to look at a proper library for it like debtcollector.

@tacaswell
Copy link
Member

👍 in principle.

This is needed right now to not re-import cbook from _api.deprecation.
It's intended anyway, but changing all occurences in the code is left
for another time to keep this PR reasonably sized.
@@ -0,0 +1,13 @@
*******************
Copy link
Member

Choose a reason for hiding this comment

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

I'm confused why we are making a documentation page for something we are making private?

Copy link
Member Author

Choose a reason for hiding this comment

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

This targets contributors. It may be easier to read this in HTML than in plaintext.

Pandas does something similar. See the warning note at https://pandas.pydata.org/docs/reference/index.html?highlight=private.

Copy link
Member

Choose a reason for hiding this comment

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

Do we need similar warnings at the beginning of _api.deprecation?

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 makes sense. I'll also extend the warning to explicitly mention that these Functions are only for developers/contributors.

Copy link
Member

Choose a reason for hiding this comment

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

We read the docs too!

Copy link
Member

Choose a reason for hiding this comment

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

Sigh, had a stale browser and only saw the first comment when I posted, sorry for the noise.

Copy link
Member

@jklymak jklymak left a comment

Choose a reason for hiding this comment

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

This seems fine to me aside from my question about the docs...


.. warning:

This module and its submodules are for internal use only.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
This module and its submodules are for internal use only.
This module and its submodules are for internal use only. We may change
the API at any time with no warning. If you want to use these functions in your
own code please vendor them.

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've chosen a slightly different expression. In particular I've left out the vendoring part. First, I'm not sure that less experienced developers know that term. But more importantly, I don't think we should/need to actively promote the possibility of vendoring. A bit philosophical: Bringing up the possibility would already imply that it could be useful for other people, but I'd rather not make any statement about external usage of this code. Users can themselves decide if they want to copy and adapt the code (n.b. some messages explicitly contain "Matplotlib").

Copy link
Member

@tacaswell tacaswell left a comment

Choose a reason for hiding this comment

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

I added a suggestion to make the wording a bit more verbose, but happy with this going in with or with out that change.

Anyone can merge this.

@timhoffm
Copy link
Member Author

I'll self merge based on @tacaswell's comment (wording still a bit more refined), otherwise we'll collect more and more conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants