Skip to content

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

Open

Description

@yvonnefroehlich

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.

(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.

Activity

  1. added
    questionFurther information is requested
    discussionsNeed more discussion before taking further actions
    on Aug 9, 2026
  2. seisman commented on Aug 10, 2026

    @seisman
    Member

    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.

    v0.20.0.dev62 means the 62nd development release for v0.20.0, rather than 62 changes since v0.20.0.

    We can't change it to something like v0.19.0.dev62, as shown below:

    >>> from packaging.version import Version
    >>> Version("0.19.0") > Version("0.19.0.dev62")
    True
    
    >>> Version("0.19.0") > Version("0.20.0.dev62")
    False
    
  3. seisman commented on Aug 10, 2026

    @seisman
    Member

    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.

    There are two version strings in GMT, the binary version and the library version. The library version string is obtained from the GMT API function GMT_Get_Version, which must be in the major.minor.patch form. The binary version comes from gmt --version.

    Perhaps we should change "version" to "library version"?

  4. added this to the 0.20.0 milestone on Aug 10, 2026
  5. yvonnefroehlich commented on Aug 10, 2026

    @yvonnefroehlich
    MemberAuthor

    Perhaps we should change "version" to "library version"?

    And maybe we can move binary version to the top and library version to the end, as I feel binary version provides the more complete version information.

  6. seisman commented on Aug 10, 2026

    @seisman
    Member

    Maybe update it to:

    GMT information:
      version: 6.7.0_8931e47_2026.01.12
      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:
    

    The reasons are:

    • Strictly speaking, some information like "share dir" are not information about "GMT library". Changing it to "GMT information" may make more sense
    • The binary version string provides more accurate information than the library version string. So just keep one of them.
  7. added
    maintenanceBoring but important stuff for the core devs
    and removed
    questionFurther information is requested
    discussionsNeed more discussion before taking further actions
    on Sep 28, 2026
  8. removed this from the 0.20.0 milestone on Oct 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    maintenanceBoring but important stuff for the core devs

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions