Opened 4 years ago
Closed 4 years ago
#676 closed enhancement (fixed)
numpy install with repro testing
Reported by: | Andreas Müller | Owned by: | |
---|---|---|---|
Priority: | minor | Component: | Package |
Version: | Keywords: | ||
Cc: |
Description
First: I like the testing repro, it looks and feels very consistent! What irritated me is the size of that installation, and identified two packages which grew strongly:
- numpy install is quite huge, because the mkl version is used, which got many binaries/dlls in the site-package directory. I propose to use the "vanilla" version, like in anaconda.
proj: in share/proj, the geoid definitions seems to be very complete ;-) May be there is a way to keep the packages small and provide the possibility to upgrade for extra functionality?
Change History (4)
comment:1 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 4 years ago
Thank you jef, I red about proj and I think you are right. As long as proj doesn't have a tool or offers a kind of subpackages, there is no easy way, to split the data. I only fear, proj-data will grow on.
comment:3 by , 4 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Since this numpy change, I have trouble using Scipy Spatial.
File "C:/Users/godet/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\***.py", line 28, in from scipy.spatial import cKDTree File "C:/OSGEO4~2/apps/qgis/./python\qgis\utils.py", line 799, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File "C:\OSGEO4~2\apps\Python39\lib\site-packages\scipy\spatial\__init__.py", line 98, in from .qhull import * File "C:/OSGEO4~2/apps/qgis/./python\qgis\utils.py", line 799, in _import mod = _builtin_import(name, globals, locals, fromlist, level) ImportError: DLL load failed while importing qhull:
I revert to numpy-MKL and the error disappeared.
comment:4 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Fixed in python3-scipy-1.6.2-2
numpy upgraded to vanilla 1.20.2.
But for proj-data I don't have a good approach. All grids are required somewhere, but nobody needs them all. And one might not even need all grids of a certain area. There's no splitting upstream either (there the preferred approach is dynamic download).