shared kernel pool for C++ & Python API

First of all, amazing work on bringing spice to Python. With that said, I’m looking for advice.

Is your feature request related to a problem? Please describe.

We have a code base for performing numerical astrodynamics in my department in C++. Some simple wrapped (seen here) functions were written around spice functions which we required for our libraries. These wrappers have become core to the functionality of our libraries. I have been exposing the entire code base to Python in order to make our libraries accessible and take advantage of the Python environment. In C++ we can use the cspice directly, and in Python, spiceypy is ideal so that I need not reinvent the wheel. I want to find a way to integrate spicepy into our Python interface (tudatpy).

Describe the solution you’d like

I want the kernel pool in our Python wrapped C++ library to share a kernel pool with spiceypy so that kernel loading (which we carry out with spice_interface.load_standard_kernels() to load our default kernels used) is common between both our C++ library wrapped with Pybind11 and your library exposed with Ctypes.

Describe alternatives you’ve considered

I see one of the potential solutions:

• Add spiceypy as a dependency for our C++ package tudat and write a FindSpice() cmake module which finds your library.

• Modify this line in spicepy/utils/libspicehelper.py to find our cspice-cmake library instead.

• Make a layer between spiceypy and tudatpy (our python wrapping) such that when either spiceypy.furnsh(*args) or tudatpy.kernel.interface.spice_interface.load_kernel() (our spice.furnsh wrapping) is called, it will load it for the other too. This would apply to kclear too.

Additional context

Could I ask you for your opinion on the best way to proceed, or for any advice you may have?

[AndrewAnnex]

Hey @ggarrett13, the documentation includes details about “offline-installation” (https://spiceypy.readthedocs.io/en/main/installation.html#offline-installation) of cspice. I think this would directly allow you to implement your 2nd alternative solution, as you would just use the environment variable to point SpiceyPy to whatever shared library you build using cmake. Looking at the code now (https://github.com/AndrewAnnex/SpiceyPy/blob/main/get_spice.py#L375), in get_spice.py my code will copy that shared library file over to the site packages file.

I think for this to work for your use case, the file would need to be a symbolic link so you could just manually overwrite that or I could add a new environment variable to indicate a symbolic link should be created instead of copying the file. That said, I really don’t have a lot of experience with cmake and other ways of binding c++ to python, so I don’t know if this will work.

I would say to try out that idea with a symbolic link to the shared library from your cmake project and see if it works first.

[AndrewAnnex]

I am closing this issue for now