Context manager for SPICE kernels

Note I’ve read the contributing guidelines and am aware that Kernels’ management interfaces are out of your scope. That being said, this could be implemented in less than a minute, and it has improved my personal experience using this library.

Is your feature request related to a problem? Please describe. I’ve been working with spicepy for the last year, and one of the only things that annoys me about it is having to use a try-except or try-finally scheme in order to assure that kernels are properly closed, even if an exception is raised. Let me show a litte example:

import spiceypy as spice

kpath = "path/to/metak"

spice.furnsh(kpath)

try:
    t0 = spice.str2et("28-06-2000")
finally:
    spice.kclear()

Describe the solution you’d like I’d like to be able to use a context manager to automatically load and unload kernels.

with Kernels(kpath):
    t0 = spice.str2et("28-06-2000")

Describe alternatives you’ve considered I’ve been working with a custom, and pretty simple, context manager that looks like this:

class Kernels:

    def __init__(self, path: str) -> None:

        spice.furnsh(path)

    def __enter__(self) -> None:

        return None

    def __exit__(self, exc_type, exc_value, traceback) -> None:

        spice.kclear()

What are your thoughts on this? I’d love to help to implement it if you were open to it.

[AndrewAnnex]

@alfonsoSR thanks for the contribution! I’ve merged your pr in #458, closing this issue.

[AndrewAnnex]

hey @alfonsoSR thanks for the detailed response, I’ve left some comments on the PR that need to be addressed but I’ll address some of your response here first.

Agree about worrying about changing directories to be out of scope, users should ensure they pass in absolute paths to kernels in general.

Secondly after looking into it a bit more I agree now with using kclear, although we could detect the type of kernel file, text kernels are so commonly used calling unload on them would end up having the same effect as kclear.

These caveats should be explained in a new docs file and in the docstrings for these functions (see other context manager PR for example…) to make it very clear to users what things to keep in mind.