Search path for extensions

Jonathan S. Shapiro shap at
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
     be obsoleted.

  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
     wrong place.

  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/

     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
losing upgrades.

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 [2] is the right approach. I think it can be done with
only a small change in 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
"trusted" hgrc.

Did I miss something?

Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC

More information about the Mercurial-devel mailing list