Extending extension lookups

Martijn Pieters mj at zopatista.com
Wed Jan 13 18:58:09 UTC 2016


I was asked by Pierre-Yves to create a proposal to support more than
just an hgext namespace for extensions bundled with Mercurial, to help
facilitate experimental extensions (see
https://www.mercurial-scm.org/wiki/ExperimentalExtensionsPlan).

Currently unqualified extensions (with no path an no prefix) are
loaded from the hgext package. To facilitate experimental extensions
to be added to a Mercurial distribution, I'm proposing that the search
for unqualified extension names is extended to include more packages;
either still hardcoded or as a configurable 'extension search path',
with 'hgext' as the first name. Where extensions.load() currently a
fixed "hgext." prefix, a loop will try to import the module from the
search path packages instead.

Experimental extensions can then be installed in a hgext_experimental
prefix, or a nested package hgext.experimental. Then, when an
extension graduates from experimental to core, noone using the
extension will have to update their configuration. "foo" will load
"hgext.foo", where previously it may have loaded
"hgext.experimental.foo".

While I'm at it, I also want to look at where extensions (3rd party or
core) are to be installed. Mercurial extensions are currently expected
to be installed in the standard Python site-packages directory. Is
there any interest in moving extension out to a new, separate
location? With a little work (like a provided hgsetup.py module),
installation of extensions can still be done with the standard Python
tools. Mercurial would add that new location to the Python module
search path on startup and loading extensions would not have to
otherwise change. But at the same time, you then guarantee that
Mercurial extensions can't be confused with 'regular' Python
libraries. Is there any interest in doing this?

-- 
Martijn Pieters


More information about the Mercurial-devel mailing list