Skip to content
Snippets Groups Projects
  1. Sep 16, 2024
    • Matt Harbison's avatar
      typing: add `from __future__ import annotations` to most files · f4733654
      Matt Harbison authored
      Now that py36 is no longer supported, we can postpone annotation evaluation.
      This means that the quoting is usually optional (for things imported under the
      guard of `if typing.TYPE_CHECKING:` to avoid circular imports), and there's less
      overhead on startup[1].
      
      There may be some missing here.  I backed out 6000f5b25c9b (which removed the
      `from __future__ import ...` that was supporting py2), reverted the changes in
      `contrib/`, `doc/`, and `tests/`, and then ran:
      
          $ hg status -n --change . | \
              xargs sed -i -e 's/from __future__ import .*$/from __future__ import annotations/'
      
      There were some minor tweaks needed when reviewing (mostly making the spacing
      around the import consistent, and `mercurial/testing/__init__.py` had a
      multiline import that wasn't fully rewritten.
      
      [1] https://docs.python.org/3/whatsnew/3.7.html#pep-563-postponed-evaluation-of-annotations
      f4733654
  2. Mar 03, 2022
  3. Oct 06, 2019
  4. Mar 11, 2016
    • Pierre-Yves David's avatar
      extensions: also search for extension in the 'hgext3rd' package · 4b81487a
      Pierre-Yves David authored
      Mercurial extensions are not meant to be normal python package/module. Yet the
      lack of an official location to install them means that a lot of them actually
      install as root level python package, polluting the global Python package
      namespace and risking collision with more legit packages. As we recently
      discovered, core python actually support namespace package. A way for multiples
      distinct "distribution" to share a common top level package without fear of
      installation headache. (Namespace package allow submodule installed in different
      location (of the 'sys.path') to be imported properly. So we are fine as long as
      extension includes a proper 'hgext3rd.__init__.py' to declare the namespace
      package.)
      
      Therefore we introduce a 'hgext3rd' namespace packages and search for extension
      in it. We'll then recommend third extensions to install themselves in it.
      Strictly speaking we could just get third party extensions to install in 'hgext'
      as it is also a namespace package. However, this would make the integration of
      formerly third party extensions in the main distribution more complicated as the third
      party install would overwrite the file from the main install. Moreover, having an
      explicit split between third party and core extensions seems like a good idea.
      
      The name 'hgext3rd' have been picked because it is short and seems explicit enough.
      Other alternative I could think of where:
      
      - hgextcontrib
      - hgextother
      - hgextunofficial
      4b81487a
Loading