hgext/__init__.py
author Pierre-Yves David <pierre-yves.david@fb.com>
Sat, 27 Feb 2016 12:56:26 +0100
changeset 28450 155e3308289c
parent 1360 7d439981bec4
child 43076 2372284d9457
permissions -rw-r--r--
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.
Ignore whitespace changes - Everywhere: Within whitespace: At end of lines:
28450
155e3308289c hgext: officially turn 'hgext' into a namespace package
Pierre-Yves David <pierre-yves.david@fb.com>
parents: 1360
diff changeset
     1
from __future__ import absolute_import
155e3308289c hgext: officially turn 'hgext' into a namespace package
Pierre-Yves David <pierre-yves.david@fb.com>
parents: 1360
diff changeset
     2
import pkgutil
155e3308289c hgext: officially turn 'hgext' into a namespace package
Pierre-Yves David <pierre-yves.david@fb.com>
parents: 1360
diff changeset
     3
__path__ = pkgutil.extend_path(__path__, __name__)