Test infrastructure for external spice kernels

[subagonsouth]

Change Summary

Overview

After discussing with @greglucas, we settled on this quick, partial implementation of what was envisioned as the ultimate solution. These changes allow the use of the the de440s.bsp kernel and can be generalized to include other generic NAIF kernels.

Most of the changes in this PR are adding to testing infrastructure.

• Ignore all flavors of de440 kernel in git repo to avoid checking in kernel downloaded from NAIF
• Formally add the pytest marker external_kernel so that tests relying on downloading/using cached kernels can be skipped in most of the github run tests.
• Add pytest collection hook that automatically adds the _download_de440s fixture to any test marked with external_kernel.
• Pull out helper functions from the fixture that generates a metakernel from template for reuse
• Add a function scoped use_test_metakernel fixture that pulls input from metakernel marker to allow specification of different metakernel template files
• Add a metakernel template for ena simulated data
• Add test coverage which exercises all of the above

New Files

• imap_processing/tests/spice/test_data/imap_ena_sim_metakernel.template
  • This will eventually contain all of the kernels needed for processing the simulated ena data

Deleted Files

N/A

Updated Files

• .gitignore
  • Ignore all flavors of de440 kernel in git repo to avoid checking in kernel downloaded from NAIF
• imap_processing/tests/conftest.py
  • Add pytest collection hook that automatically adds the _download_de440s fixture to any test marked with external_kernel.
  • Pull out helper functions from the fixture that generates a metakernel from template for reuse
  • Add a function scoped use_test_metakernel fixture that pulls input from metakernel marker to allow specification of different metakernel template files
• imap_processing/tests/spice/test_geometry.py
  • Add test coverage which exercises all of the above
• pyproject.toml
  • Formally add the pytest marker external_kernel so that tests relying on downloading/using cached kernels can be skipped in most of the github run tests.

[laspsandoval]

What else do you envision will go here besides _download_de440s?

[subagonsouth]

It is possible that certain tests could require other large external kernels be downloaded.

[laspsandoval]

logger.info("Kernel successfully downloaded: %s", local_filepath)

[laspsandoval]

    if local_filepath.exists():
        logger.info("Kernel file already exists: %s", local_filepath)
        return
    allowed_attempts = 3
    for attempt_number in range(allowed_attempts):

etc.

[laspsandoval]

Nice!

[laspsandoval]

I'm curious how this will affect codecov checks. For example, if I skip a test codecov complains that there weren't enough tests.

[subagonsouth]

Good question. I don't know how codecov works. It looks like all of the various test runs upload results to the same commit in codecov and so my assumption is that it uses the latest upload. This would mean that the last one to run is the one that gets used in the final check?

[greglucas]

They all get combined together actually. So you can skip all but one runner for this. This is also useful for combining Windows-specific, Mac-specific, and Linux-specific behaviors to ensure all your code coverage for those specific platforms gets added together.

[laspsandoval]

Nice work. Looks like some of the test aren't passing. I had a few suggestions, but otherwise looks great. Probably just a couple of minor edits. Ping me and I'll hit the approve button.

[greglucas]

I like this approach of downloading it somewhere local and .gitignoreing that, good idea!

An interesting approach because I think this will basically force me into downloading it during the tests, whereas I was thinking we'd do a skipif(specific_kernel_not_available) and then have the user run a helper function before the test if they wanted that coverage for example. I kind of like this injection method I think, we'll see once I actually pull it down and test though ;)

Writing this out so I don't forget later, but not relevant for taking action in this PR:

I still have in the back of my mind an idea that I think we might be able to combine all this great kernel management stuff into a singleton class KernelManager, which would have a few methods like load(), download(), write_metakernel(), ... combining basically all of your helper functions here taking care of all loading/unloading of everything. Something like that seems like it might be generically useful. Then in the ensure_spice decorator, we'd check that singleton class for are_kernels_loaded() rather than having the try/except on the spiceypy errors, and could set up some fallbacks to go back to the KernelManager and try to load from the environment variable etc.