Repository navigation
MNT: Have a plan to retire vo_conesearch #2027
Description
At Astropy Coordination Meeting 2021, @tomdonaldson mentioned a desire to replace vo_conesearch with something else (probably with something in pyvo?). We need to formulate a transition plan with a timeline.
Activity
bsipocz commentedon Mar 26, 2021
Would you have that something else in astroquery or rather a "how-to" for using pyvo for doing cone search?
tomdonaldson commentedon Mar 26, 2021
Since
pyvoalready supports doing a VO standard cone search, this may mostly be an exercise in clearly documenting the alternative approach in thevo_conesearchdocumentation, then deprecatingvo_conesearch. I want to look more carefully at what value-added featuresvo_conesearchoffers to see if there are things that should be added topyvo.Based on the decisions we've had before regarding VO image searches and TAP searches, I think it is most consistent for the generic cone search capability to live in pyvo. Then, as with TAP, if an astroquery API for a specific resource wants to utilize that feature, it can.
pllim commentedon Mar 26, 2021
In the spirit of PEP 20, "There should be one-- and preferably only one --obvious way to do it," I agree with you that PyVO should be the true home of cone search, and will be happy to work with you to make that happen. We can start with documentation, but I still want a path towards deprecation and eventual removal.
Besides the API here, I do keep a daily cron job to vet select services but I am really not sure if anyone is even using it.
TBH,
vo_conesearchis at the "if it ain't broken, don't fix it" stage, as I am not really getting paid to maintain it anymore.bsipocz commentedon Aug 9, 2022
@tomdonaldson and @pllim - Would be nice to deprecate the module in favour of pyvo in the next release (coming out in the next few months or so), so we can actually remove it sometimes in the future. What do you think? Is there a plug-and-play tutorial or similar that can be linked-to in the docs as an alternative?
pllim commentedon Aug 9, 2022
I will be happy to help but pyvo devs need to take the lead on this. I have not been involved in VO stuff for years. I just pop in once in a while to put out fires. 😬
bsipocz commentedon Aug 9, 2022
I'll cross open an issue in pyvo, too.
pllim commentedon Feb 16, 2026
Looks like most services are "dead" on https://astroconda.org/aux/vo_databases/ . Only
gsss.stsci.eduis listed now. I don't have time to maintain this, so hopefully no one is using this anymore? 😬bsipocz commentedon Feb 16, 2026
Ok, let's gut it out.
pllim commentedon Feb 18, 2026
@bsipocz what is the plan now? Please advise. Thanks!
bsipocz commentedon Feb 18, 2026
If you open up a removal pr I would merge it. If it has to wait for me to do it, it may take a bit longer as it's not at the top of my own list to do.
bsipocz commentedon Feb 18, 2026
Or we could start with a deprecation for now and full removal later in the autumn. I suppose that would be a bit more preferable if there is still some working components around.
pllim commentedon Feb 18, 2026
There is a replacement in pyvo, right?
bsipocz commentedon Feb 18, 2026
People can do SCS with pyvo yes. It's not a 1-to-1 direct replacement though, at least in my understanding (but to be honest, I never saw what this module was being used for, or if it was used at all)
11 remaining items
bsipocz commentedon Feb 19, 2026
I would really like it gone and nudge people towards using pyvo directly. This is legacy code and I really prefer not to do any maintenance on it but focus any efforts on community tools like pyvo.
bsipocz commentedon Feb 19, 2026
(and this one is really an odd ball in astroquery and only ended up here as a refugee after being kicked out from astropy. It actually should have not ended up here at all)
pllim commentedon Feb 19, 2026
A transition guide might be nice. 🤔
bsipocz commentedon Feb 19, 2026
Who is writing it? I was floated as an idea before, but always stuck at at that point, and honestly at this point I may not want that existence/non-existence of that guide to be the blocker on ultimately removing this from astroquery.
pllim commentedon Feb 19, 2026
I can assist from
vo_conesearchside but will need to work with someone familiar with the cone search over atpyvo. Probably a hack day sort of thing.ManonMarchand commentedon Feb 23, 2026
vo_conesearchhas server-side functionalities that don't exist in pyVO. We can document how people using the client-side can switch, but the rest won't have replacements (which is ok if no one uses it). I can help write/review such a document.pllim commentedon Feb 23, 2026
The server validation stuff was nice in principle when it was envisioned but I think in practice, people already have a list of servers they trust anyway, so my guess is no one actually uses it. @jehturner , does your team use it?
pllim commentedon Feb 26, 2026
@jehturner , in regards to #2027 (comment) , do you have a list of requirements or desired features, so we can be sure this transition will not be too hard on your team? Thanks!
jehturner commentedon Feb 26, 2026
I don't think we're using any special validation; our code queries specific URLs anyway. We really just do a simple
conesearch()in one place in the code and we've now replaced that withpyvo.dal.SCSService(url).search()in the DRAGONS repo, so hopefully it's just a case of doing enough testing 🤞. Thanks!pllim commentedon Mar 4, 2026
OK I have not heard any objection, so I can take a stab at this.
pllim commentedon Mar 4, 2026
@bsipocz , do you want something like astropy/astropy#5904 , or do you just want the warning to appear on import from like vo_conesearch/__init__.py ?
bsipocz commentedon Mar 4, 2026
I would leave it to your judgement, either would work.
(I prefer the import time, the option in astropy is just unusefully verbose, all we want just one warning at the very top of the usage. )
pllim commentedon Mar 4, 2026
Please point stakeholders to review #3548 . Thanks!