Skip to content

Report the extension and keyring module versions in `hg version -v`

Matt Harbison requested to merge topic/default/report-version into branch/default

Given the history of compatibility issues between the extension and the keyring module, as well as compatibility issues between the keyring module and the OS or some behavior differences depending on the version of the keyring module, it's a good idea to have the information available for bug reports. This is similar to how the built in git extension reports its pygit2 dependency.

The mechanism used to figure out the version value was originally how the keyring module filled in a __version__ attribute[1], but was subsequently removed due to overhead.[2] Since this method is only called on demand instead of on load, I think the overhead is worth having the info. Even if a manually maintained __version__ attribute is added, this mechanism would be needed to get the keyring module version.

In testing this, I hit a case a few months ago where using pkg_resources would raise a cryptic error about modules having been replaced since they were loaded. It worked in most cases, though when I hit it, it was completely reproducible. It was related to demandimport, but comparing the modules loaded with and without demandimport enabled and adding the differences to the disable list didn't help. Wrapping the try/catch that imports pkg_resources with demandimport.disable() fixed the problem, but when I commented that out now to reproduce the issue, I couldn't. It's been tested in WSL with py2.7.15, and py3.8.0, the TortoiseHg package on Windows (py2.7.18), py3.8.1 in a venv on Windows, and py3.9.0 on Windows from a Mercurial source based installation.

[1] https://github.com/jaraco/keyring/blob/9066fbf0abee465bbe230e0e76d2598a9f08569c/keyring/__init__.py#L9 [2] https://github.com/jaraco/keyring/blob/main/CHANGES.rst#1100

Merge request reports