Support both major numpy versions for PyHC Env inclusion?

[sapols]

Is your feature request related to a problem? Please describe.
Yes. The PyHC Environment is a dockerized container deployed in Binder that contains all published PyHC packages. SpiceyPy has been in it since day one, but as of yesterday, the latest version v6.0.1 is incompatible because it requires numpy>=2.0,<3 which conflicts with the environment's requirement of numpy>=1.26.4,<2.0.0. I've temporarily pinned SpiceyPy to v6.0.0, preventing new versions from being installed until we address this conflict.

Describe the solution you'd like
Will you please consider supporting both major versions of numpy? All other PyHC packages using numpy 2 have found backwards compatible workarounds that support both.

Describe alternatives you've considered
SpiceyPy will simply remain pinned at v6.0.0 until this dependency conflict is resolved. That's a shame for the environment though, we want the latest versions of all PyHC packages.

Additional context
I saw in PyPI that v6.0.1 seems to be your first release in almost two years. Congrats on making the release! Sorry to make a problem for you so soon after!

[AndrewAnnex]

@sapols thanks for writing in. Pinning to v6.0.0 is fine for the moment as v6.0.1 fixes a typo bug specific to a single function that remained undiscovered for a very long time, but SpiceyPy will be updated significantly at version 7.0.0 to include a new cython based wrapper submodule supported by a NASA PDART grant. As part of that, I am using Cython >3.0, and recent improvements to NumPy's C api post 2.0 are motivating me for the moment to keep that version pin.

Because of this, I am hesitant to change this for the next major version release for SpiceyPy. I would need some assistance with Cython/Numpy compilation to see if there is a way to update things to allow me to use the last of the numpy 1.0 releases along side 2.0.

For the moment, let's assume I will not make any changes, what are the reasons for PyHC to block numpy version 2 and newer? Is a significant portion of the PyHC environment compiled against the older numpy versions? I am just poking at how well justified that constraint is, from my experience the python api itself hasn't changed that significantly, and the version bump is mostly a c level thing. Plus given the importance of numpy, other critical packages like scipy are all making similar choices here so SpiceyPy may not be the only package with this constraint.

With that all said though, the version pin for numpy was mostly done out of convenience and to minimize the diff with the forthcoming v7.0.0. I could make a new release (v6.0.3) that rolls that back if absolutely necessary.

[sapols]

Thanks for the quick reply, @AndrewAnnex. Congrats on the NASA PDART grant. To answer your question, I'll first agree that the PyHC environment requiring numpy<2 is far from ideal. You guessed it, it's because many other PyHC packages (particularly older, less maintained ones) still haven't made the switch. Given how many PyHC packages there are, and how many recursive dependencies they share, it's kind of a miracle we're still able to make one environment that can import the latest PyHC package versions together. It has certainly taken some community coordination on my end; SpiceyPy is not the first package to get an issue from me related to numpy and/or matplotlib versions.

As I mentioned, all other packages I've confronted about this have found backwards compatible workarounds—albeit sometimes at the expense of hacks like if numpy.version < 2 then blah else blah. And I'm sure the feasibility of that varies for each project. SpiceyPy's inclusion in PyHC is not dependent on being compatible with the environment, I just think it'd be a shame to have a package pinned to an old version, no longer being updated.

But again I do recognize that requiring support for the old numpy isn't ideal, and I'm hopeful that efforts like the upcoming PHEP 3 will standardize our version update cycles to the point that everyone eventually leaves numpy 1 behind. We just aren't there yet.

[AndrewAnnex]

@sapols I researched this issue more and I believe the solution from the Numpy 2.0 migration guide applies here.

I've created a new release for v6.0.2 that uses numpy>=1.23.5 as the version pin that I believe should avoid the issue with 6.0.1's pin, and I believe can be used for the eventual 7.0.0 release I plan to make that will contain the compiled extension.

So for the moment I think it's safe to pin to 6.0.2 and when I do release 7.0.0 we can look at this again to see if the pin for PyHC can be relaxed. So I will close this issue for the time being