[PATCH] hgext: officially turn 'hgext' into a namespace package
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Wed Mar 9 10:05:14 EST 2016
On 02/28/2016 01:45 AM, Gregory Szorc wrote:
> On Sat, Feb 27, 2016 at 4:44 AM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
> wrote:
>
> # HG changeset patch
> # User Pierre-Yves David <pierre-yves.david at fb.com
> <mailto: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.)
No complains, not sure why.
This is a special enough case that that I think we should stick to the
canonical path (as in thi patch)
> +__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.
I don't have access to the windows machine but since this comes from the
standard library I'm going to assume this works fine with the other
standard library crazyness.
--
Pierre-Yves David
More information about the Mercurial-devel
mailing list