Repository navigation
Remove astropy.vo sub-package #5558
Description
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.vo sub-package now that vo.samp has been moved out as well via #6213 .
Activity
astrofrog commentedon Dec 5, 2016
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.
[-]Deprecate Cone Search in favor of Astroquery?[/-][+]Move Cone Search out of core?[/+]pllim commentedon Dec 5, 2016
Okay. I updated the title to be less confusing then.
pllim commentedon Dec 7, 2016
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.
pllim commentedon Feb 9, 2017
My understanding from tag-up:
astroquery. Does this need to happen at the same time as Step 1, or can this happen afterwards during Step 3?Is my understanding correct, @eteq and @keflavich ?
astrofrog commentedon Feb 9, 2017
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.
bsipocz commentedon Feb 9, 2017
@pllim - If No2 happens before v2.0, then No1 can be skipped and conesearch can have a proper deprecation warning from 2.0. That case the the full code can be removed in 3.0 and use astroquery instead (under the hood).
keflavich commentedon Feb 9, 2017
We 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.
bsipocz commentedon Feb 9, 2017
@astrofrog - This time you were a bit faster :)
eteq commentedon Feb 9, 2017
re 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:
astrofrog commentedon Feb 9, 2017
In the very long term we can remove it completely though, right?
astrofrog commentedon Feb 9, 2017
Just to check, are we including vo.validator in this plan?
2 remaining items
pllim commentedon Feb 9, 2017
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.astrofrog commentedon Feb 9, 2017
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).
keflavich commentedon Feb 9, 2017
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.
pllim commentedon Feb 9, 2017
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.
bsipocz commentedon Feb 9, 2017
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 ;)
pllim commentedon Feb 28, 2017
@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.
keflavich commentedon Feb 28, 2017
@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.
pllim commentedon Mar 18, 2017
The port to Astroquery is astropy/astroquery#859
[-]Move Cone Search out of core?[/-][+]Remove astropy.vo sub-package[/+]pllim commentedon Sep 9, 2017
@bsipocz , do you think it is time for this to happen or you want to wait until during or after the coordination meeting?
astrofrog commentedon Sep 9, 2017
I think this can be done now?
bsipocz commentedon Sep 9, 2017
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.