search

skyfielders / python-skyfield

Elegant astronomy for Python
MIT License
1.38k stars 208 forks source link

Compatibility with Numpy 2.0 and Python 3.12 #898

Open pllim opened 10 months ago

pllim commented 10 months ago

They are different beasts but probably can kill two birds with one stone. Actions offer Python 3.12 ("dev") and NumPy has nightly wheel for 2.0 in https://anaconda.org/scientific-python-nightly-wheels/numpy

djhoese commented 9 months ago

This work should also probably add python_requires to the setup.py to safely drop support for older versions of Python:

https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#python-requires

Edit: And/or could switch to a pyproject.toml file to describe the build system.

djhoese commented 9 months ago

Oh you'll also need to drop usage of distutils completely as it is removed in Python 3.12:

https://github.com/skyfielders/python-skyfield/blob/dda493b0849f1d01dd939a55546689eb6a733a70/setup.py#L3-L8

bnavigator commented 5 months ago

Also: https://github.com/brandon-rhodes/assay/issues/15 is still an issue with Python 3.12

bnavigator commented 5 months ago

Oh you'll also need to drop usage of distutils completely as it is removed in Python 3.12:

You can still use it when you use the setuptools backport.

brandon-rhodes commented 5 months ago

I just tested and was able to pip install Skyfield just fine under Python 3.12, and computing a planetary position seemed to work fine. The only feature that raised an error was python -m skyfield, and so I just landed a fix (the commit should show up just above this comment) and so the next release of Skyfield should work fine with Python 3.12, I think?

bnavigator commented 5 months ago

But you can't run your unit tests to be sure, can you?

brandon-rhodes commented 5 months ago

But you can't run your unit tests to be sure, can you?

Indeed not! Alas. So many bytecode operations have been removed that the introspection magic in assay will need to be rewritten — and of course might not even be possible to rewrite, as it depended on the happenstance that four instructions was enough to call an arbitrary compare function. Maybe instead of waiting until I have time to sit down and do a deep dive into Python bytecode, I should adjust assay so that it can fallback to running tests without introspection. We'll see what happens.

brandon-rhodes commented 5 months ago

Wow. Completely unrelated to assert introspection, I just spent an hour wading into how exception traceback line numbers work in relation to context managers, because a change in Python 3.10 broke the assert_raises() callable in assay.

(Where "broke" means, it's no longer showing the user which of their line numbers raised the faulty exception, but instead shows the line number of the assert_raises() context manager itself.)

That's enough of a foray to indicate that the changes to Python in the past couple of years have been substantial enough that I won't just casually be able to digest them in an hour or so — I'll need to think about priorities, and when I can spend maybe a few days working on either getting assay and its test suite working with all the disruptions in more recent Python versions. Or else maybe abandon assay and rewrite Skyfield's whole test suite to use unittest instead? I wonder if there are any modern tools that support standard unittest but do assert introspection efficiently. (I tried py.test early on but it's far too slow for me to be interested in its assert introspection; it would be several seconds, if I recall, just to import Skyfield and its dependencies.)

bnavigator commented 5 months ago

It's called pytest nowadays and I doubt that it takes several seconds to just import skyfield. The pytest.raises() context manager is used in many far bigger projects than yours.