Use lightkurve's cache instead of maintaining our own

[warrickball]

Instead of trying to maintain our own caching system, why not just rely on lightkurve? This simplifies query_lightkurve to just go ahead and use lightkurve to retrieve the data, rather than going through launch_query and lookup_cached_files to see if its in the cache manually. If we want to be aggressive with this PR, launch_query and lookup_cached_files can be removed as they aren't called anywhere else (I don't think).

The downside with lightkurve's caching is that, as far as I can tell, there's no simple option for bypassing the cache and forcing data to be downloaded again. But it can be done manually (by deleting the relevant cached files) and someone can open an issue against lightkurve or open a PR to implement it if they like.

I tried to preserve the ValueError that was produced if no data is found. Happy to tweak this if you send me some examples I should check.

[warrickball]

It turns out that lightkurve's caching goes through astroquery, with the side-effect that even if you've downloaded the data, it won't work if you're offline. There's already a lightkurve issue on this, which has led to an issue and two related pull requests in astroquery.

So we shouldn't merge this until those PRs are resolved and, hopefully, astroquery won't require us to be online to retrieve cached data. For now, @nielsenmb's existing code is a good enough workaround.

[grd349]

@nielsenmb @warrickball Any news on this from the lightkurve/astropy side? Will this PR likely just become the specification of the latest version of lk or astropy?

[nielsenmb]

I have something in the pipe for this for PBjam. It's not part of a Lightkurve PR or anything though.

…

On Wed, 1 Jul 2020, 20:59 Guy Davies, ***@***.***> wrote: @nielsenmb <https://github.com/nielsenmb> @warrickball <https://github.com/warrickball> Any news on this from the lightkurve/astropy side? Will this PR likely just become the specification of the latest version of lk or astropy? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEJWO32UFLSRM2VJPEZFYFLRZOIQ7ANCNFSM4LGPSOOA> .

[warrickball]

I just had a look at the PRs and issues I linked before and it looks like there hasn't been any activity. Unless we want to poke, we provably just want to stick to our own caching system.

I opened this issue before I was aware that lightkurve/astroquery have their own caching issues. You're welcome to close this while we wait to see if they get patched, or leave this open to keep reminding us to do so.

[grd349]

@nielsenmb I guess you want to leave this open as you say you are working on something?

[nielsenmb]

Yep, it's just a function that caches the search result with a timestamp nothing fancy. I need to make it work for TESS and K2 data, but then it should be ready to add. I'm just not sure I want to add too much that might break things until after the paper is accepted.

…

On Thu, 2 Jul 2020 at 13:30, Guy Davies ***@***.***> wrote: @nielsenmb <https://github.com/nielsenmb> I guess you want to leave this open as you say you are working on something? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEJWO3YTLVIUNEP5G6BHFGDRZR4VHANCNFSM4LGPSOOA> .

[nielsenmb]

LK's lookup is much faster now so no need for this anymore I think.