numpy 2.0 removed np.float_

[pllim]

Numpy: 2.0.0.dev0+git20230828.ef0fd39
...
skyfield/timelib.py:7: in <module>
    from numpy import (
E   ImportError: cannot import name 'float_' from 'numpy' (numpy/__init__.py)

xref https://github.com/astropy/astropy/pull/15235

[pllim]

Yeah, sorry, this patch is incomplete and I don't have time to do more. I would recommend you run CI using numpy nightly wheel and fix the incompatibility more fully. I also recommend a job with Python 3.12rc2.

[pllim]

Someone else should address this properly. I opened #898

[brandon-rhodes]

Thanks, in any case, for pointing out this upcoming change. Skyfield will be more prepared thanks to your pointing it out!

If I may editorialize:

I am dismayed. I think that the NumPy folks entirely misunderstand software. My guess is that hundreds of projects, many of which don't have authors any more and will never get updated again, will suddenly break because of these terrible changes to NumPy — and the folks responsible for keeping those systems running might not even be programmers, and will have no idea how to pin a dependency (the old scripts they are responsible for just say pip install numpy, and they won't know about the == operator) or how to edit Python code to make all the changes that this new version of NumPy requires.

And no one that I have ever seen actually writes pip install numpy>=1.0<2.0 to save themselves from future breakage. If everyone did, then NumPy's actions here would be conscionable. But people don't, and so I think the changes are indefensible.

I cannot imagine that someone thinks that causing tens of thousands of people pain — many of which are not programmers and might never get their tools working again — is worth saving the few characters needed to keep a synonym like float_ working for all future generations.

[pllim]

Thank you for your response. I see the pain downstream (which I experience very often now from their nightly wheel) but I also see why they would take 2.0 as an opportunity to get in breaking changes that they couldn't for a long time under 1.x (astropy also does breaking changes once in a while, for better or worse, but I hope mostly for the better).

FWIW, Python itself also is changing as well. There are talks about no-GIL Python and Python 3.12 deprecated datetime.datetime.utcnow(). ❗

Back to NumPy, if it helps, they have an announcement issue at https://github.com/numpy/numpy/issues/24300 . Their developers are also on the Discord listed in https://scientific-python.org/community/ .

Thanks again for your work on this package!

[brandon-rhodes]

I also see why they would take 2.0 as an opportunity to get in breaking changes…

I suppose I think that the whole idea of '2.0' is an illusion: because Python install tools don't enforce specifying the major version number, following 1.49 with a release of 2.0 is no different for anyone than a release of 1.50 — the number is just window dressing. The only reality is that a new version is out, and a million installs and CI tasks fail the next day. Bumping the major version number doesn't matter, really, except to make maintainers feel better about hurting people. People are going to look up the error they're getting and (hopefully) find instructions they can use about pinning a version number. (But what if it's an automated task they don't have permission to edit any more, after the consultant left last year?) Whether the little formula they see says numpy<1.50 or numpy<2.0, their project is still broken, and it requires the same amount of work to fix.

I suppose I should turn this into a blog post arguing against Semantic Versioning, and arguing for — what should I call it? 'Brandon versioning'? Two rules:

• Start the project at 0.1, and increment to 0.x each time. Make as many breaking changes as you want.
• Decide to commit, and release 1.0. Forever after, release 1.x, and keep all promises made by the API forever.

It's interesting that, so far as I know, Linux actually commits to keeping everything working forever (yay!), but yet they do sometimes bump the major version number, even though I don't think it requires all binaries to be recompiled? I haven't read up on their recent use of version numbers, though. Maybe I should, if I'm going to have such strong opinions about it.

[djhoese]

I was going to try to help with the float_ import problems with numpy 2.0 as skyfield is a dependency of a dependency on one of my own projects, but sad to see this PR doesn't cover all the numpy 2.0 compatibility issues. I'm not sure I know anything about skyfield to go any deeper than changing this import.

That said, I'm sorry to hear some of these opinions. At the end of the day you're mad at numpy for trying to make their lives and the maintenance of their library easier for them. If you want the library to improve then it is unrealistic to expect backwards compatibility forever. At least they aren't doing it in a 1.26.x "patch" release. They've been very good about nightly wheels of numpy 2.0, making announcements about the changes (deprecation warnings, email announcements, etc), and getting out Python 3.12 wheels early to fix any compatibility issues with Python 3.12 and the loss of distutils. Numpy may have some funding now, but at the end of the day they are working very hard on a library that many depend on and get for free.

I feel like your discussion on unmaintained projects is missing a major point. I read it as "how will these tools that are unmaintained continue to be unmaintained". They won't and can't. That is the very nature of something that isn't being maintained. As the world changes around us, some things may get left behind. Software is no different and as we all learn to manage software better it is no longer reasonable to treat software as a one-time investment. Treating the release of a software tool or the first production deployment as the end of that development lifecycle doesn't work anymore and we all need to learn that. Laying the foundation of a business or research on a single set of tools that no one maintains is a mistake. As a someone who writes software for researchers, software maintenance and contributions really needs to be written into proposals more.

It's interesting that, so far as I know, Linux actually commits to keeping everything working forever (yay!), but yet they do sometimes bump the major version number, even though I don't think it requires all binaries to be recompiled? I haven't read up on their recent use of version numbers, though.

That's because the majority of software doesn't interact with the kernel beyond basic system calls. The software that does like kernel drivers do need to be rebuilt or workaround compatibility issues between versions or between platforms or between processors just like other software.

Please be nice to the numpy folks. They do a lot for us and I'm not sure these updates are unreasonable or that we can pretend to know how they made things easier for them.