GenericMappingTools / GenericMappingTools/pygmt
Improve reporting the GMT version via "pygmt.show_versions()"
- Dominant language
- Python
- Stars
- 874
- Forks
- 255
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 40
Description
Currently, `pygmt.show_versions()` reports the GMT version in two different ways: `version` and `binary version`. In the example below, `version` says `6.7.0`. So one may think GMT 6.7.0 is successfully installed. However, `binary version` says `6.7.0_8931e47_2026.01.12`. This indicates that the installed GMT version is actually GMT 6.6.0 with changes towards 6.7.0 but not the finally released GMT 6.7.0. I feel this can be misleading. In contrast, for PyGMT, we have `v0.20.0.dev62` under `version`. So, it's directly clear that this is v0.19.0 with changes towards v0.20.0 and not the finally released v0.20.0. When running `gmt --version` I get `6.7.0_8931e47_2026.01.12`, which is the same output as listed for `binary version`.
```bash
(pygmt_env_dev) C:\Users\Admin>python -c "import pygmt; pygmt.show_versions()"
PyGMT information:
version: v0.20.0.dev62
System information:
python: 3.14.2 | packaged by conda-forge | (main, Dec 6 2025, 11:17:27) [MSC v.1944 64 bit (AMD64)]
executable: C:\ProgramData\Anaconda3\envs\pygmt_env_dev\python.exe
machine: Windows-10-10.0.19045-SP0
Dependency information:
numpy: 2.4.1
pandas: 2.3.3
xarray: 2025.12.0
packaging: 25.0
contextily: 1.7.0
geopandas: 1.1.2
IPython: 9.9.0
pyarrow: 22.0.0
rioxarray: 0.20.0
gdal: 3.12.1
ghostscript: 10.06.0
GMT library information:
version: 6.7.0
padding: 2
share dir: C:/Program Files (x86)/gmt6/share
plugin dir: C:/ProgramData/Anaconda3/envs/pygmt_env_dev/Library/bin/gmt_plugins
library path: C:/ProgramData/Anaconda3/envs/pygmt_env_dev/Library/bin/gmt.dll
cores: 4
grid layout: rows
image layout:
binary version: 6.7.0_8931e47_2026.01.12
(pygmt_env_dev) C:\Users\Admin>gmt --version
6.7.0_8931e47_2026.01.12
```
---
Beside this, I personally find it confusing to write `v0.20.0.dev62` for v0.19.0 with changes towards v0.20.0 (or v0.19.1). At the beginning I thought that the latest release is v0.20.0 with 62 changes towards the next release. Thus, I think it would be more intuitive to write `v0.19.0.dev62`. But probably doing it in the current way is the common practice. So better not changing this.
Contributor guide
Research direction
Start at the implementation of `pygmt.show_versions()` and inspect how the GMT `version` and `binary version` fields are obtained and displayed. Compare this with `gmt --version`; done should make the reported GMT version unambiguously reflect whether it is a released version or a development build, with tests covering the output.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- developer-experience
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100