- Jun 14, 2024
-
-
Marcin Kasperski authored
-
Marcin Kasperski authored
-
- Dec 09, 2022
-
-
Matt Harbison authored
I hit this on Ubuntu 22.04 with Mercurial 6.3.1. No idea who is to blame. The list was determined using the usual technique[1], but I didn't bother trying to reduce the list. Also of note is a bunch of Cryptodome modules not being loaded when demandimport is used. I wonder if it wouldn't be better to use `hgdemandimport.deactivate()` (a context manager that goes back to hg 3.5 in mid 2015) to wrap the import of `keyring`. The documentation in the py3 implementation explicitly says that disable() and then enable() may not work as expected on py3. OTOH, I tripped over a bug[2] in hg 6.3.1 doing this, so something might need to be monkeypatched. [1] #76 (comment 154188) [2] mercurial-devel@48e38b179106
-
- Mar 26, 2022
-
-
Marcin Kasperski authored
-
Marcin Kasperski authored
-
Marcin Kasperski authored
-
Marcin Kasperski authored
Report the extension and keyring module versions in `hg version -v` See merge request !17
-
Marcin Kasperski authored
-
Marcin Kasperski authored
-
- Mar 15, 2022
-
-
Matt Harbison authored
-
- Apr 21, 2021
-
-
Marcin Kasperski authored
-
Marcin Kasperski authored
-
Jeroen Ruigrok van der Werven authored
This was probably missed from the comments in !15 This fixes my keyring issues due to poetry enforcing a keyring version < 22.
-
- Apr 12, 2021
-
-
Matt Harbison authored
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. There appears to be a demandimport issue with py3 prior to 3.8: $ ../hg version Mercurial Distributed SCM (version 5.7.1+hg562.1afb49f11377local20210415) (see https://mercurial-scm.org for more information) Copyright (C) 2005-2021 Olivia Mackall and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Traceback (most recent call last): File "/mnt/c/Users/Matt/projects/foss/mercurial/mercurial_keyring/mercurial_keyring.py", line 899, in _getversion dist = pkg_resources.get_distribution(mod) File "/usr/lib/python3.6/importlib/util.py", line 233, in __getattribute__ self.__spec__.loader.exec_module(self) File "<frozen importlib._bootstrap_external>", line 678, in exec_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 74, in <module> from pkg_resources.extern import packaging File "<frozen importlib._bootstrap>", line 971, in _find_and_load File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 656, in _load_unlocked File "<frozen importlib._bootstrap>", line 629, in _load_backward_compatible File "/usr/lib/python3.6/importlib/util.py", line 238, in __getattribute__ raise ValueError(f"module object for {original_name!r} " ValueError: module object for 'pkg_resources._vendor.packaging' substituted in sys.modules during a lazy load I was unable to fix it by comparing the modules loaded with and without demandimport enabled and adding the differences to the disable list, so demandimport is temporarily toggled off. (I've seen this done in TortoiseHg, which gave me the idea to try it.) Since this is only called with `version -v` and to generate bug reports, I think it's fine. This has been tested in WSL with py2.7.15, py3.6.9, py3.7.5 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
-
- Mar 04, 2021
-
-
Marcin Kasperski authored
-
Marcin Kasperski authored
-
Marcin Kasperski authored
seems to work more or less.
-
Marcin Kasperski authored
Topic/default/py3 fixes See merge request !16
-
- Feb 28, 2021
-
-
Marcin Kasperski authored
-
Marcin Kasperski authored
-
- Feb 22, 2021
-
-
Chris Wesseling authored
-
- Feb 21, 2021
-
-
Matt Harbison authored
Aside from the customization of fetching the password from the store, I left the default config arg for `smtp.tls` and the `util.safehasattr(socket, 'ssl')` check for TLS to support ancient Mercurial versions. I think this area could be improved greatly by changing Mercurial to have a separate function that fetches the username/password that this extension could wrap and replace, and another function that can be given a username/password to try the login. That would eliminate a lot of code duplication that I'm not entirely convinced is py3 safe in core Mercurial, such as passing the exception to `error.Abort` a couple lines below.
-
Matt Harbison authored
Mercurial both wants and returns bytes from these.
-
- Nov 23, 2020
-
-
Matt Harbison authored
This is a thin wrapper around `mercurial.i18n._()` and as noted in the previous commit, that is not meant to handle unicode. We could fix that function to convert internally before passing through, but I'm used to passing bytes to these Mercurial internals, and every time I saw it I thought these needed to be fixed. Additionally, if translations are ever made, it should probably be done in the same manner as core Mercurial (based on bytes). The trailing arguments are converted to bytes by `ui_string()` before interpolation, so this won't introduce any incompatabilities.
-
Matt Harbison authored
As noted in 4a2d0ce50f5a, it's not intended for _() to convert from unicode, and it doesn't always work. For the uses where values are interpolated, they will not be `None`, given the checks that precede them.
-
- Nov 22, 2020
-
-
Matt Harbison authored
At this point, there are no more things that pytype is flagging, so it will need some annotations on core Mercurial code.
-
Matt Harbison authored
The makefile and config file were copied from TortoiseHg. The location of the `mercurial-extension_utils` repo is assumed to be next to this repo for simplicity.
-
Matt Harbison authored
I hit this in various test-check-* tests for Mercurial when running on a zstd repo without the C extensions, but this can be trivially reproduced with `HGPLAIN=1`: *** failed to import extension mercurial_keyring: unicode 'keyring_check [PATH]' found in cmdtable.keyring_check *** (use b'' to make it byte string) The issue is that `i18n._()` wants bytes, but leaves a backdoor for `str` for docstrings. That backdoor is closed if `HGPLAIN` or `HGPLAINEXCEPT` is set (unless `i18n` is set in `HGPLAINEXCEPT`). There are a bunch of other uses of this function that still need to be byteified. The global `buglink`, `testedwith`, and `minimumhgversion` also want to be bytes.
-
- Feb 20, 2021
-
-
Marcin Kasperski authored
-
- Aug 08, 2020
-
-
Anton Shestakov authored
There were no clickable links to thg before.
-
Anton Shestakov authored
-
Anton Shestakov authored
-
Anton Shestakov authored
-
Anton Shestakov authored
An identical link already exists at the bottom of this file.
-
- Feb 20, 2021
-
-
Marcin Kasperski authored
-