[PATCH] hgext: officially turn 'hgext' into a namespace package
yuya at tcha.org
Thu Mar 10 21:22:57 EST 2016
On Wed, 9 Mar 2016 15:05:14 +0000, Pierre-Yves David wrote:
> 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.
Actually there was. check-py3-compat.py fails to ignore an empty file that
only contains comments.
I've updated this patch to absolute_import and pushed to the clowncopter,
> 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.
This appears to be harmless with py2exe. hgext.__path__ is the same as before
More information about the Mercurial-devel