Extension dependencies / extension loading order

Mateusz Kwapich mitrandir at fb.com
Fri Dec 4 16:50:57 UTC 2015


Extension dependencies / extension loading order. Moving discussion from irc:

In facebook we do have a lot of extensions enabled and some of them are changing the ordering in extensions._order during uisetup step for various reasons:

  *   Extensions have dependencies on other extensions and so their extsetup *must* be run after those.
  *   Extensions that work better if they are set up as late as possible  (for example extension setting default destinations for rebase and histedit wants to run after any other extension touching those (not only after just rebase.py and histedit.py)).
  *   Extensions that work better if they are set up as soon as possible (they want to be as close to the real code as possible: because they touch internals, or because other popular extension is breaking things for them).

Also sometimes in concrete deployment of mercurial you know the better order of loading your extensions because of known interaction problems or because of performance reason. For example if one wrapper for command is able to exit early we want to run it before the others). To facilitate our usecase I made a quick hack to write this extension:

https://bpaste.net/show/0b12870b7f4a

lcharignon and pyd suggested that we should think about introducing this feature to core instead making it an extension.

mpm had correctly suggested that for basic dependency management we do have afterloaded callbacks.  Maintaining dependencies via callbacks is quite powerful but it's making the code less readable than setting the list of deps somewhere and it’s not helping with all our ordering issue (the help only with the first bullet point).

Let’s discuss if we need better extension loading order management in core and what’s the best way to expose it.

Mateusz Kwapich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151204/586846e9/attachment.html>


More information about the Mercurial-devel mailing list