I build the GMT master branch from source code and install it to /home/user/opt/GMT-master/. It's the only GMT version installed on my computer.

Here is the output of pygmt.show_versions()

>>> import pygmt
>>> pygmt.show_versions()
PyGMT information:
  version: v0.6.1.dev3+g26d72c896
System information:
  python: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0]
  executable: /home/user/opt/miniconda/bin/python
  machine: Linux-5.15.18-200.fc35.x86_64-x86_64-with-glibc2.34
Dependency information:
  numpy: 1.22.3
  pandas: 1.4.1
  xarray: 2022.3.0
  netCDF4: 1.5.8
  packaging: 21.3
  ghostscript: 9.55.0
  gmt: 6.4.0_434ed18_2022.03.11
GMT library information:
  binary dir: /home/user/opt/miniconda/bin
  cores: 80
  grid layout: rows
  image layout: 
  library path: /home/user/opt/GMT-master/lib64/libgmt.so
  padding: 2
  plugin dir: /home/user/opt/GMT-master/lib64/gmt/plugins
  share dir: /home/user/opt/GMT-master/share
  version: 6.4.0

There are some issues here:

1. It should also report the version information of optional dependencies (i.e., geopandas) if available
2. The GMT version information gmt: 6.4.0_434ed18_2022.03.11 is obtained by calling gmt --version. However, when multiple GMT versions are installed, the command gmt and the library libgmt may come from different GMT verisons. For example, if I have GMT 6.3 in my conda environment and GMT dev in another installation path, PyGMT may load the GMT 6.3 library but find GMT dev comman, or vice versa, depending on the settings of PATH and GMT_LIBRARY_PATH. It causes some confusion because PyGMT reports inconsistent GMT versions. I think we should remove the gmt: 6.4.0_434ed18_2022.03.11 information.
3. The GMT's binary dir: /home/user/opt/miniconda/bin information comes from GMT's API_BINDIR parameter in libgmt. It's the path of the program that loads and call the libgmt library. So, for GMT CLI, it points to GMT's bin directory, but for PyGMT, it's the path of the python interpreter. So the information is useless and also cause some confusion. I think we should remove it too.