Looking at the backtrace doesn't seem related to keyring or meu. Mercurial isn't always right in the way it blames extensions.
Verify in usual way: temporarily disable keyring and meu (if you enabled meu explicite) and retry. Trying to commit doesn't require working keyring.
Marcin Kasperski (2f5f48e3) at 12 Sep 06:29
Version number set to 1.0.5
Marcin Kasperski (8bfc7600) at 12 Sep 06:29
Added tag 1.0.5 for changeset 3f61f855b7c3
... and 3 more commits
Marcin Kasperski (52d1c341) at 26 May 09:42
Version number set to 1.2.0
Marcin Kasperski (b38aedec) at 26 May 09:42
Added tag 1.2.0 for changeset b4bf5f479e2d
... and 4 more commits
I try to support as old versions, as possible (in mercurial_keyring, and in other extensions) – still have users of hg 4.0.2, for example.
Regarding version … I accepted your patch which uses pkg_resources, but I can simply revert to constant if that causes problems (I use https://pypi.org/project/mercurial_update_version/ while tagging so that's not major maintanance hassle). Does it make sense?
Released in 1.4.3.
I slightly fixed the patch so it works for older mercurials too, and added info about selected backend:
$ hg version -v
…
mercurial_keyring external 1.4.3 (keyring 23.5.0, backend keyring.backends.SecretService)
…
Let's see whether it works OK.
Marcin Kasperski (d413d59d) at 26 Mar 13:25
Version number set to 1.4.3
Marcin Kasperski (6b637777) at 26 Mar 13:25
Added tag 1.4.3 for changeset 45bb7687400e
... and 2 more commits
Marcin Kasperski (7df86457) at 26 Mar 13:14
Fix for older mercurials (tested on 4.1)
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
Marcin Kasperski (c07a5cb1) at 26 Mar 13:03
Marcin Kasperski (e6685e44) at 26 Mar 13:03
Merge branch 'topic/default/report-version' into 'branch/default'
... and 1 more commit
Marcin Kasperski (414de66f) at 26 Mar 12:56
Version number set to 1.4.2
Marcin Kasperski (56a16333) at 26 Mar 12:56
Added tag 1.4.2 for changeset 16c49ce09ebd
... and 1 more commit
Marcin Kasperski (2af8140b) at 26 Mar 12:56
history entry
Marcin Kasperski (ab988401) at 26 Mar 12:50
Add support for hg 6.1
Marcin Kasperski (ab988401) at 26 Mar 12:50
Thank you, I had busy weekend but will try to make release within few day.