deprecation warnings from pyvo incorrectly indicate an Astropy issue

[falkben]

The deprecated decorator which is imported from astropy produces warnings that indicate that the deprecation comes from Astropy instead of pyvo.

Could the deprecation warnings be reworked so that they correctly indicate that the deprecation is in pyvo instead of astropy?

Perhaps the decorator could still be reused from astropy but adapted for pyvo. it looks like if you pass warning_type or pending_warning_type with custom pyvo classes it might resolve this issue.

[bsipocz]

Can you provide a code example please?

[falkben]

Can you provide a code example please?

Of calling into deprecated with custom classes or of the error message showing Astropy warnings?

[bsipocz]

I mean it never came up as an issue in any of the other packages (astroquery, photutils, etc.) so it would be good to see if the tracebacks are that misleading that it's not clear that the trigger line is in pyvo instead of astropy.

[falkben]

These are the warnings we get with multiple mentions to Astropy:

mast/vo_tap/services/vosi_router_test.py::TestPyvoVOSI::test_pyvo_availability
  /Users/bfalk/miniconda3/envs/vo-tap-mast/lib/python3.12/site-packages/astropy/utils/decorators.py:836: AstropyDeprecationWarning: The availability function is deprecated and may be removed in a future version.
    val = self.fget(obj)

mast/vo_tap/services/vosi_router_test.py::TestPyvoVOSI::test_pyvo_availability
  /Users/bfalk/miniconda3/envs/vo-tap-mast/lib/python3.12/site-packages/pyvo/dal/vosi.py:65: AstropyDeprecationWarning: The _availability function is deprecated and may be removed in a future version.
    return vosi.parse_availability(self._availability().read)

[bsipocz]

OK, so upstream precedent is in sunpy, but not in astropy coordinated/affiliates, so while we could do this, it requires some boilerplate to make it work so it may or may not happen in time for the next release.