Repository navigation
Remove astropy.vo sub-package #5558
Description
Activity
Astroquery focuses mostly on non-VO interfaces to specific services. We definitely need a more generic VO-compliant cone search. We can still debate whether this should be in PyVO or another affiliated package instead of the core though.
Reacted by P. L. Lim- changed the title
[-]Deprecate Cone Search in favor of Astroquery?[/-][+]Move Cone Search out of core?[/+]on Dec 5, 2016 Okay. I updated the title to be less confusing then.
Looks like PyVO already has some kind of Cone Search (https://github.com/pyvirtobs/pyvo/blob/24bb57c7ccba5719d9dc28036e43f7dcb23fe28f/pyvo/dal/scs.py) but the interface is different. Does not look like it provides a default list of services nor support Quantity. This does not look as straightforward as I hope.
My understanding from tag-up:
- Add "pending deprecation warning" to Cone Search for v2.0 (last before release?).
- Move Cone Search to
astroquery. Does this need to happen at the same time as Step 1, or can this happen afterwards during Step 3? - Replace "pending deprecation warning" with "deprecation warning" in 2.x? Or does this need to be v3.0?
- Completely remove Cone Search from core Astropy.
Is my understanding correct, @eteq and @keflavich ?
We should basically add the full (not pending) deprecation warning once there is a stable release of astroquery out which has the cone search functionality.
Reacted by P. L. LimWe can schedule a new release of astroquery for immediately after the cone search PR merge. We've done this in the past for urgent changes.
Reacted by Brigitta SipőczReacted by P. L. Lim@astrofrog - This time you were a bit faster :)
Reacted by Thomas Robitaille and P. L. Limre 2: I'd say definitely want to get it in astroquery by 2.0 to make the warning says "you should start moving to astroquery now", basically.
I'd also say we just go straight to deprecation warning in 2.0 and not worry about the pending step (as @astrofrog said).
The other thing to clarify is that for 4, we aren't going to completely remove it, but rather replace all the implementation by just something like:
def cone_search(* args, **kwargs): from astroquery.conesearch improt cone_search warn(...) return cone_search(*args, **kwargs)Reacted by P. L. LimIn the very long term we can remove it completely though, right?
Just to check, are we including vo.validator in this plan?
2 remaining items
Re: validator -- It is only used for Cone Search. I am hoping it is no longer needed with the move to astroquery but I need to actually look at astroquery first. 😅
AFAIK, I am the only one in the world who actually uses the validator...
To clarify: I am talking about the validator within
astropy.vo. I am not touching the one inastropy.io.votable.One thing to think about is that 2.0 is an LTS. If we import functions from astroquery we can't guarantee they won't break (since astroquery can choose to update the API of those functions).
It doesn't really make sense to have "astroquery LTS" because remote things can and do break, but we can commit to a fixed API for cone search.
I agree with @keflavich in regards to remote services having no respect for our LTS, so LTS or not, there is never guarantee that Cone Search would work for a given version of Astropy.
With so many things in astroquery (and even more that would be great to have in there), it's super easy to promise not touching a module and focus on the other ones ;)
@keflavich , so in reading the Astroquery doc, it says service should have some common API, but that would break backward compatibility with Astropy if you want people to still be able to run it from Astropy. A translation layer might be overly complicated for the async stuff due to the way it is currently implemented. Please advise.
@pllim we can have a submodule in astroquery that implements things identically to astropy, but ideally we'd like to have a compatibility layer that is the "service" with a common API. If we can't handle the async stuff, that's fine - it's not heavily used even though it was a very clever idea.
We strive for a common API in astroquery, but often miss because external services don't always allow for a common API. So, we do our best and document exceptions. Astroquery isn't a core library, so we can get away with this.
Reacted by P. L. LimThe port to Astroquery is astropy/astroquery#859
- changed the title
[-]Move Cone Search out of core?[/-][+]Remove astropy.vo sub-package[/+]on Jun 16, 2017 I think this can be done now?
I think we should do a big removal party at the meeting for python2 to be fair and share the treat, but no need to wait with this one.
Reacted by P. L. Lim
Discussions started from this comment in 5546. Not sure if it is feasible as I am not familiar with Astroquery. Futher discussions should go here.
c/c @bsipocz @keflavich
Update: For v3, we can completely remove
astropy.vosub-package now thatvo.samphas been moved out as well via #6213 .