Skip to content
Snippets Groups Projects
  1. Jun 14, 2024
  2. Dec 09, 2022
    • Matt Harbison's avatar
      Update direct import list for keyring 23.11.0 and cryptography 38.0.4 on Linux · ea0f9b8b
      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
      ea0f9b8b
  3. Mar 26, 2022
  4. Mar 15, 2022
  5. Apr 21, 2021
  6. Apr 12, 2021
    • Matt Harbison's avatar
      Report the extension and keyring module versions in `hg version -v` · 8784ee61
      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
      8784ee61
  7. Mar 04, 2021
  8. Feb 28, 2021
  9. Feb 22, 2021
  10. Feb 21, 2021
    • Matt Harbison's avatar
      Synchronize `keyring_supported_smtp()` with core `mail._smtp()` · acc24307
      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.
      acc24307
    • Matt Harbison's avatar
      Byteify all `ui.config()` calls · 7ad91f57
      Matt Harbison authored
      Mercurial both wants and returns bytes from these.
      7ad91f57
  11. Nov 23, 2020
    • Matt Harbison's avatar
      Byteify the message argument to `ui_string()` · e4e41ce8
      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.
      e4e41ce8
    • Matt Harbison's avatar
      Byteify the message argument to `mercurial.i18n._()` · 85ba8256
      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.
      85ba8256
  12. Nov 22, 2020
    • Matt Harbison's avatar
      Disable a couple of pytype errors related to conditionalized compatability · 88665ac9
      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.
      88665ac9
    • Matt Harbison's avatar
      Add infrastructure for running `pytype` · dfd2957e
      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.
      dfd2957e
    • Matt Harbison's avatar
      Byteify registered command help and the `buglink` attribute · 4a2d0ce5
      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.
      4a2d0ce5
  13. Feb 20, 2021
  14. Aug 08, 2020
  15. Feb 20, 2021
Loading