Search path for extensions
Jonathan S. Shapiro
shap at eros-os.com
Thu Aug 30 00:23:57 CDT 2007
PLEASE NOTE: If you see a reason NOT to do this, please let me know
There is a problem with the current extension search strategy: it is not
friendly for packagers.
Consider an extension like forest. This is something that a lot of
people are using now, and it is very tempting to build a third-party
add-on package for some of my customers before it moves into the central
distribution. The problem is that there is no good way for an add-on RPM
to install it.
Today, I have three choices:
1. Build a RPM that puts it in site-packages/hgext. Later, when
forest moves into the distributed package set, and the "official"
package is updated to include it, there will be an update
collision, because Fedora will not know that my package should
2. Put it somewhere else (e.g. site-packages/hgext-shap), and tell
people to activate it with hgext-shap= in their [extensions]
section. The problem with this is that they will not be upgraded
back to the "official" version when forest moves into the core
distribution, because their [extensions] section is naming the
3. Rotten apples, if any should go to Brendan for this one:
Implement a trivial package that appends a new directory to
the python sys.path during the reposetup() callback. Load this
package in /etc/hgrc with something like:
__path_hack = path/to/disgusting-path-hack.py
any extensions that are initialized later than this will see
the updated sys.path.
Brendan thinks this will work because extensions (he thinks)
are initialized in alphabetical order. Looking at the code I am not
convinced that this is actually true.
In any case, it is a horrible, disgusting hack (but congratulations
to Brendan on the quality of his dirty mind :-).
So the problem is that I have to choose between breaking updates or
There seem to be two solutions:
1. Define an "official" path for user-added extensions that is not
hgext. It seems to me that this only repeats the problem
2. Provide a mechanism in hgrc for the user or site administrator
to append directories to sys.path during startup. This needs
to be done before extensions are loaded, which seems to suggest
that it belongs in a new configuration section. Perhaps
I believe that  is the right approach. I think it can be done with
only a small change in command.py before load_extensions() is called.
Do people agree that this seems like a good idea? If so, I would like to
build a patch quickly so that we can back-port it into the 0.9.4 Fedora
RPM. That will let me (and others) package add-ons in an upgrade-safe
Since extensions are able to alter sys.path in the way the Brendan
proposed, there is no new security problem here that did not already
exist. At least if it is in an hgrc section the user can actually see
what is happening by reading the hgrc!
Obviously, an [extensions-dirs] section should only be processed from a
Did I miss something?
Jonathan S. Shapiro, Ph.D.
The EROS Group, LLC
More information about the Mercurial-devel