Geert Barentsen

@orionlee Thank you for posting the MWE as a bokeh issue!

Thanks for opening this issue @warrickball! Opening issues is the first step towards getting all the kinks ironed out of Lightkurve v2. I appreciate it! This looks like a real...

Side note: because `LightCurve` objects are now AstroPy tables, they can now be saved in FITS and other formats as follows: ```python lc.write("filename.fits") ``` This works in the example posted...

@JosephKarpinski Thank you for reporting this issue! There is no reader function for light curve files produced by the K2SC yet. This is in part because the number of light...

Thank you for raising this idea @christinahedges, and for posting an example solution @orionlee! For completeness, I'll add that an author priority system can of course also be implemented using...

> I feel the complexity is not necessarily just in the codes, but also the API we expose. I fully agree! In fact I think reducing API complexity is 100x...

For anyone interested in volunteering to work on this, I'll add that we are currently using the `cached` decorator from the `memoization` package for this purpose, e.g. here: https://github.com/KeplerGO/lightkurve/blob/58c9b2de2d7a70ddf751cea6b11b459c2e65cf6b/lightkurve/search.py#L540-L545 This...

Idea: we could expose the cache as `from lightkurve import cache`, and allow users to use `lk.cache.clear()` to address certain caching issues.

@JWCook Thank you for reaching out. `requests-cache` looks like a fabulous package! The vast majority our requests calls are handled by the `astroquery` package, so I wonder if we ought...

@orionlee @scfleming You both hit the nail on the head! A Kepler target such as "KIC 5385723" is known in the MAST Portal API under `target_name="kplr005385723"`. Thus, some string manipulation...