-
Notifications
You must be signed in to change notification settings - Fork 239
Closed
Labels
maintenanceBoring but important stuff for the core devsBoring but important stuff for the core devs
Milestone
Description
>>> import pygmt
>>> pygmt.show_versions()
PyGMT information:
version: v0.17.0.dev11+g0c57126f35
System information:
python: 3.13.5 | packaged by conda-forge | (main, Jun 16 2025, 08:23:50) [Clang 18.1.8 ]
executable: /opt/miniforge/envs/pygmt/bin/python3.13
machine: macOS-14.6.1-x86_64-i386-64bit-Mach-O
Dependency information:
numpy: 2.3.0
pandas: 2.3.0
xarray: 2025.6.1
packaging: 25.0
contextily: 1.6.2
geopandas: 1.1.0
IPython: 9.3.0
pyarrow: 20.0.0
rioxarray: 0.19.0
gdal: None
ghostscript: 10.04.0
GMT library information:
version: 6.5.0
padding: 2
share dir: /opt/miniforge/envs/pygmt/share/gmt
plugin dir: /opt/miniforge/envs/pygmt/lib/gmt/plugins
library path: /opt/miniforge/envs/pygmt/lib/libgmt.dylib
cores: 8
grid layout: rows
image layout:
binary version: 6.5.0Currently, we use the importlib library to obtain the GDAL version, but this only works when the GDAL Python bindings are installed.
Six months ago, we updated GMT's dependency from gdal to libgdal-core (see conda-forge/gmt-feedstock@48fb3f0), so now only the GDAL C library is included, without the Python bindings. This explains why importlib fails.
Potential solutions:
- Use
subprocessto callgdalinfo --versionand parse the output - Use ctypes to obtain the GDAL version directly from the C library
- No longer query the GDAL version
I have no strong preferences. Which one do you prefer? Or do you have a better solution?
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
maintenanceBoring but important stuff for the core devsBoring but important stuff for the core devs