GenericMappingTools / GenericMappingTools/pygmt

Improve reporting the GMT version via "pygmt.show_versions()"

Open Beginner friendly
#4,812 4 comments 0 reactions 0 assignees View on GitHub
discussions question
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.