Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Warn if running on older numpy than astropy is compiled with?
See original GitHub issueCurrently, if one builds and installs with numpy >=1.16, but then attempts to run astropy with numpy < 1.16, several modules will not work (e.g., _erfa). Should we emit a warning upon importing astropy in this situation? It would mean to somehow keep track of the numpy version used to build (e.g., by writing an check.py file as part of the build and installation).
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (9 by maintainers)
Top Results From Across the Web
RuntimeError: module compiled against API version a but this ...
PYTHONPATH was finding the older version of numpy before the correct version, so when inside the Python interpreter, it would import the older...
Read more >Installation — Astropy v5.2
In most cases, this will install a pre-compiled version (called a wheel) of astropy, but if you are using a very recent version...
Read more >Known Issues — Astropy v1.0.4
Upgrading Astropy in the anaconda python distribution using pip can result in a corrupted install with a mix of files from the old...
Read more >NumPy 1.12.0 Release Notes
The old behavior can be obtained by using indexing to reorder the fields before ... np.average will emit a warning if the argument...
Read more >Release Notes — NumPy v1.16 Manual
2 and, if using OpenBLAS, OpenBLAS > v0.3.4. If you are installing using pip, you may encounter a problem with older installed versions...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Any package with C extensions that depends on Numpy is going to have the same issue (I’ve seen this with a number of them). I’m reluctant to add yet more astropy-specific layers of infrastructure, especially if we are trying to phase out astropy-helpers in future - maybe it would be better to solve this issue in a way that can work for all packages using Numpy C extensions?
Yes, I think this can be closed. Thanks!