[PATCH] hgext: officially turn 'hgext' into a namespace package

[Gregory Szorc]

On Sat, Feb 27, 2016 at 4:44 AM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

> # HG changeset patch
> # User Pierre-Yves David <pierre-yves.david at fb.com>
> # Date 1456574186 -3600
> #      Sat Feb 27 12:56:26 2016 +0100
> # Node ID 5f942a1ffe3974a1827b02bb21dcb2d4494852bb
> # Parent  41dcd754526612c43b9695df8851557c851828ef
> # Available At http://hg.netv6.net/marmoute-wip/mercurial/
> #              hg pull http://hg.netv6.net/marmoute-wip/mercurial/ -r
> 5f942a1ffe39
> hgext: officially turn 'hgext' into a namespace package
>
> Actually since Python 2.3, there is some way to turn top level package
> into "namespace
> package" so that multiple subpackage installed in different part of the
> path can
> still be imported transparently. This feature was previously thought (at
> least
> by myself) to be only provided by some setuptool black magic.
>
> Turning hgext into such namespace package allows third extensions to
> install
> themselves inside the "hgext" namespace package to avoid polluting the
> global
> python module namespace. They will now be able to do so without making it
> a pain
> to use a Mercurial "installed" in a different way/location than these
> extensions.
>
> The only constrains is that the extension ship a 'hgext/__init__.py'
> containing
> the same call to 'pkgutil.extend_path' and nothing else. This seems
> realistic.
>
> The main question that remains is: should we introduce a dedicated
> namespace for
> third party extension (hgext3rd?) to make a clearer distinction between
> what is
> officially supported and what is not? If so, this will be introduced in a
> follow
> up patch.
>
> diff --git a/hgext/__init__.py b/hgext/__init__.py
> --- a/hgext/__init__.py
> +++ b/hgext/__init__.py
> @@ -1,1 +1,2 @@
> -# placeholder
> +from pkgutil import extend_path
>

This violates our import conventions (we only allow direct symbol imports
from mercurial.i18n and mercurial.node). Does test-module-imports.t not
complain? (A possibility since this file doesn't use absolute_import.)


> +__path__ = extend_path(__path__, __name__)
>

I'd test this on Windows with the zip importer before queuing since the zip
importer has historically caused problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160227/2c5595f1/attachment.html>