Compatibility with Numpy 2.0 and Python 3.12

[pllim]

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]

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]

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

python-skyfield/setup.py

Lines 3 to 8 in dda493b

	if 'SKYFIELD_USE_SETUPTOOLS' in os.environ:
	import setuptools
	print('Using setuptools version', setuptools.__version__)
	from distutils.core import setup
	from distutils.command.sdist import sdist

[bnavigator]

Also: brandon-rhodes/assay#15 is still an issue with Python 3.12

[bnavigator]

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]

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]

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

[brandon-rhodes]

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]

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]

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.