|
@@
-0,0
+1,321
b''
|
|
|
1
|
Extensions allow the creation of new features and using them directly from
|
|
|
2
|
the main hg command line as if they were built-in commands. The extensions
|
|
|
3
|
have full access to the *internal* API.
|
|
|
4
|
|
|
|
5
|
Use of Mercurial's internal API very likely makes your code subject to
|
|
|
6
|
Mercurial's license. Before going any further, read the License page.
|
|
|
7
|
|
|
|
8
|
There are NO guarantees that third-party code calling into Mercurial's
|
|
|
9
|
internals won't break from release to release. If you do use Mercurial's API
|
|
|
10
|
for published third-party code, we expect you to test your code before each
|
|
|
11
|
major Mercurial release. This will prevent various bug reports from your users
|
|
|
12
|
when they upgrade their copy of Mercurial.
|
|
|
13
|
|
|
|
14
|
File Layout
|
|
|
15
|
===========
|
|
|
16
|
|
|
|
17
|
Extensions are usually written as simple python modules. Larger ones are
|
|
|
18
|
better split into multiple modules of a single package (see the convert
|
|
|
19
|
extension). The package root module gives its name to the extension and
|
|
|
20
|
implements the ``cmdtable`` and optional callbacks described below.
|
|
|
21
|
|
|
|
22
|
Command table
|
|
|
23
|
=============
|
|
|
24
|
|
|
|
25
|
To write your own extension, your python module can provide an optional dict
|
|
|
26
|
named ``cmdtable`` with entries describing each command. A command should be
|
|
|
27
|
registered to the ``cmdtable`` by ``@command`` decorator.
|
|
|
28
|
|
|
|
29
|
Example using ``@command`` decorator (requires Mercurial 1.9)::
|
|
|
30
|
|
|
|
31
|
from mercurial import cmdutil
|
|
|
32
|
from mercurial.i18n import _
|
|
|
33
|
|
|
|
34
|
cmdtable = {}
|
|
|
35
|
command = cmdutil.command(cmdtable)
|
|
|
36
|
|
|
|
37
|
@command('print-parents',
|
|
|
38
|
[('s', 'short', None, _('print short form')),
|
|
|
39
|
('l', 'long', None, _('print long form'))],
|
|
|
40
|
_('[options] node'))
|
|
|
41
|
def printparents(ui, repo, node, **opts):
|
|
|
42
|
...
|
|
|
43
|
|
|
|
44
|
The cmdtable dictionary
|
|
|
45
|
-----------------------
|
|
|
46
|
|
|
|
47
|
The ``cmdtable`` dictionary uses as key the new command names, and, as value,
|
|
|
48
|
a tuple containing:
|
|
|
49
|
|
|
|
50
|
1. the function to be called when the command is used.
|
|
|
51
|
2. a list of options the command can take.
|
|
|
52
|
3. a command line synopsis for the command (the function docstring is used for
|
|
|
53
|
the full help).
|
|
|
54
|
|
|
|
55
|
List of options
|
|
|
56
|
---------------
|
|
|
57
|
|
|
|
58
|
All the command flag options are documented in the mercurial/fancyopts.py
|
|
|
59
|
sources.
|
|
|
60
|
|
|
|
61
|
The options list is a list of tuples containing:
|
|
|
62
|
|
|
|
63
|
1. the short option letter, or ``''`` if no short option is available
|
|
|
64
|
(for example, ``o`` for a ``-o`` option).
|
|
|
65
|
2. the long option name (for example, ``option`` for a ``--option`` option).
|
|
|
66
|
3. a default value for the option.
|
|
|
67
|
4. a help string for the option (it's possible to omit the "hg newcommand"
|
|
|
68
|
part and only the options and parameter substring is needed).
|
|
|
69
|
|
|
|
70
|
Command function signatures
|
|
|
71
|
---------------------------
|
|
|
72
|
|
|
|
73
|
Functions that implement new commands always receive a ``ui`` and usually
|
|
|
74
|
a ``repo`` parameter. The rest of parameters are taken from the command line
|
|
|
75
|
items that don't start with a dash and are passed in the same order they were
|
|
|
76
|
written. If no default value is given in the parameter list they are required.
|
|
|
77
|
|
|
|
78
|
If there is no repo to be associated with the command and consequently no
|
|
|
79
|
``repo`` passed, then ``norepo=True`` should be passed to the ``@command``
|
|
|
80
|
decorator::
|
|
|
81
|
|
|
|
82
|
@command('mycommand', [], norepo=True)
|
|
|
83
|
def mycommand(ui, **opts):
|
|
|
84
|
...
|
|
|
85
|
|
|
|
86
|
For examples of ``norepo``, see the convert extension.
|
|
|
87
|
|
|
|
88
|
Command function docstrings
|
|
|
89
|
===========================
|
|
|
90
|
|
|
|
91
|
The docstring of your function is used as the main help text, shown by
|
|
|
92
|
``hg help mycommand``. The docstring should be formatted using a simple
|
|
|
93
|
subset of reStructuredText markup. The supported constructs include:
|
|
|
94
|
|
|
|
95
|
Paragraphs::
|
|
|
96
|
|
|
|
97
|
This is a paragraph.
|
|
|
98
|
|
|
|
99
|
Paragraphs are separated
|
|
|
100
|
by blank lines.
|
|
|
101
|
|
|
|
102
|
A verbatim block is introduced with a double colon followed by an indented
|
|
|
103
|
block. The double colon is turned into a single colon on display::
|
|
|
104
|
|
|
|
105
|
Some text::
|
|
|
106
|
|
|
|
107
|
verbatim
|
|
|
108
|
text
|
|
|
109
|
!!
|
|
|
110
|
|
|
|
111
|
We have field lists::
|
|
|
112
|
|
|
|
113
|
:key1: value1
|
|
|
114
|
:key2: value2
|
|
|
115
|
|
|
|
116
|
Bullet lists::
|
|
|
117
|
|
|
|
118
|
- foo
|
|
|
119
|
- bar
|
|
|
120
|
|
|
|
121
|
Enumerated lists::
|
|
|
122
|
|
|
|
123
|
1. foo
|
|
|
124
|
2. bar
|
|
|
125
|
|
|
|
126
|
Inline markup::
|
|
|
127
|
|
|
|
128
|
``*bold*``, ``monospace``, :hg:`command`
|
|
|
129
|
|
|
|
130
|
Mark Mercurial commands with ``:hg:`` to make a nice link to the corresponding
|
|
|
131
|
documentation. We'll expand the support if new constructs can be parsed
|
|
|
132
|
without too much trouble.
|
|
|
133
|
|
|
|
134
|
Communicating with the user
|
|
|
135
|
===========================
|
|
|
136
|
|
|
|
137
|
Besides the ``ui`` methods, like ``ui.write(*msg)`` or
|
|
|
138
|
``ui.prompt(msg, default="y")``, an extension can add help text for each
|
|
|
139
|
of its commands and the extension itself.
|
|
|
140
|
|
|
|
141
|
The module docstring will be used as help string when ``hg help extensionname``
|
|
|
142
|
is used and, similarly, the help string for a command and the docstring
|
|
|
143
|
belonging to the function that's wrapped by the command will be shown when
|
|
|
144
|
``hg help command`` is invoked.
|
|
|
145
|
|
|
|
146
|
Setup Callbacks
|
|
|
147
|
===============
|
|
|
148
|
|
|
|
149
|
Extensions are loaded in phases. All extensions are processed in a given phase
|
|
|
150
|
before the next phase begins. In the first phase, all extension modules are
|
|
|
151
|
loaded and registered with Mercurial. This means that you can find all enabled
|
|
|
152
|
extensions with ``extensions.find`` in the following phases.
|
|
|
153
|
|
|
|
154
|
ui setup
|
|
|
155
|
--------
|
|
|
156
|
|
|
|
157
|
Extensions can implement an optional callback named ``uisetup``. ``uisetup``
|
|
|
158
|
is called when the extension is first loaded and receives a ui object::
|
|
|
159
|
|
|
|
160
|
def uisetup(ui):
|
|
|
161
|
# ...
|
|
|
162
|
|
|
|
163
|
Extension setup
|
|
|
164
|
---------------
|
|
|
165
|
|
|
|
166
|
Extensions can implement an optional callback named ``extsetup``. It is
|
|
|
167
|
called after all the extension are loaded, and can be useful in case one
|
|
|
168
|
extension optionally depends on another extension. Signature::
|
|
|
169
|
|
|
|
170
|
def extsetup():
|
|
|
171
|
# ...
|
|
|
172
|
|
|
|
173
|
Mercurial version 8e6019b16a7d and later (that is post-1.3.1) will pass
|
|
|
174
|
a ``ui``` argument to ``extsetup``::
|
|
|
175
|
|
|
|
176
|
def extsetup(ui):
|
|
|
177
|
# ...
|
|
|
178
|
|
|
|
179
|
Command table setup
|
|
|
180
|
-------------------
|
|
|
181
|
|
|
|
182
|
After ``extsetup``, the ``cmdtable`` is copied into the global command table
|
|
|
183
|
in Mercurial.
|
|
|
184
|
|
|
|
185
|
Repository setup
|
|
|
186
|
----------------
|
|
|
187
|
|
|
|
188
|
Extensions can implement an optional callback named ``reposetup``. It is
|
|
|
189
|
called after the main Mercurial repository initialization, and can be used
|
|
|
190
|
to setup any local state the extension might need.
|
|
|
191
|
|
|
|
192
|
As other command functions it receives an ``ui`` object and a ``repo`` object
|
|
|
193
|
(no additional parameters for this, though)::
|
|
|
194
|
|
|
|
195
|
def reposetup(ui, repo):
|
|
|
196
|
#do initialization here.
|
|
|
197
|
|
|
|
198
|
It is important to take into account that the ``ui`` object that is received
|
|
|
199
|
by the ``reposetup`` function is not the same as the one received by the
|
|
|
200
|
``uisetup`` and ``extsetup`` functions. This is particularly important when
|
|
|
201
|
setting up hooks as described in the following section, since not all hooks
|
|
|
202
|
use the same ``ui`` object and hence different hooks must be configured in
|
|
|
203
|
different setup functions.
|
|
|
204
|
|
|
|
205
|
Wrapping methods on the ui and repo classes
|
|
|
206
|
-------------------------------------------
|
|
|
207
|
|
|
|
208
|
Because extensions can be loaded *per repository*, you should avoid using
|
|
|
209
|
``extensions.wrapfunction()`` on methods of the ``ui`` and ``repo`` objects.
|
|
|
210
|
Instead, create a subclass of the specific class of the instance passed into
|
|
|
211
|
the ``*setup()`` hook; e.g. use ``ui.__class__`` as the base class, then
|
|
|
212
|
reassign your new class to ``ui.__class__`` again. Mercurial will then use
|
|
|
213
|
your updated ``ui`` or ``repo`` instance only for repositories where your
|
|
|
214
|
extension is enabled (or copies thereof, reusing your new class).
|
|
|
215
|
|
|
|
216
|
For example::
|
|
|
217
|
|
|
|
218
|
def uisetup(ui):
|
|
|
219
|
class echologui(ui.__class__):
|
|
|
220
|
def log(self, service, *msg, **opts):
|
|
|
221
|
if msg:
|
|
|
222
|
self.write('%s: %s\n' % (service, msg[0] % msg[1:]))
|
|
|
223
|
super(echologui, self).log(service, *msg, **opts)
|
|
|
224
|
|
|
|
225
|
ui.__class__ = echologui
|
|
|
226
|
|
|
|
227
|
Configuring Hooks
|
|
|
228
|
=================
|
|
|
229
|
|
|
|
230
|
Some extensions must use hooks to do their work. These required hooks can
|
|
|
231
|
be configured manually by the user by modifying the ``[hook]`` section of
|
|
|
232
|
their hgrc, but they can also be configured automatically by calling the
|
|
|
233
|
``ui.setconfig('hooks', ...)`` function in one of the setup functions
|
|
|
234
|
described above.
|
|
|
235
|
|
|
|
236
|
The main difference between manually modifying the hooks section in the hgrc
|
|
|
237
|
and using ``ui.setconfig()`` is that when using ``ui.setconfig()`` you have
|
|
|
238
|
access to the actual hook function object, which you can pass directly to
|
|
|
239
|
``ui.setconfig()``, while when you use the hooks section of the hgrc file
|
|
|
240
|
you must refer to the hook function by using the
|
|
|
241
|
``python:modulename.functioname`` idiom (e.g. ``python:hgext.notify.hook``).
|
|
|
242
|
|
|
|
243
|
For example::
|
|
|
244
|
|
|
|
245
|
# Define hooks -- note that the actual function name it irrelevant.
|
|
|
246
|
def preupdatehook(ui, repo, **kwargs):
|
|
|
247
|
ui.write("Pre-update hook triggered\n")
|
|
|
248
|
|
|
|
249
|
def updatehook(ui, repo, **kwargs):
|
|
|
250
|
ui.write("Update hook triggered\n")
|
|
|
251
|
|
|
|
252
|
def uisetup(ui):
|
|
|
253
|
# When pre-<cmd> and post-<cmd> hooks are configured by means of
|
|
|
254
|
# the ui.setconfig() function, you must use the ui object passed
|
|
|
255
|
# to uisetup or extsetup.
|
|
|
256
|
ui.setconfig("hooks", "pre-update.myextension", preupdatehook)
|
|
|
257
|
|
|
|
258
|
def reposetup(ui, repo):
|
|
|
259
|
# Repository-specific hooks can be configured here. These include
|
|
|
260
|
# the update hook.
|
|
|
261
|
ui.setconfig("hooks", "update.myextension", updatehook)
|
|
|
262
|
|
|
|
263
|
Note how different hooks may need to be configured in different setup
|
|
|
264
|
functions. In the example you can see that the ``update`` hook must be
|
|
|
265
|
configured in the ``reposetup`` function, while the ``pre-update`` hook
|
|
|
266
|
must be configured on the ``uisetup`` or the ``extsetup`` functions.
|
|
|
267
|
|
|
|
268
|
Marking compatible versions
|
|
|
269
|
===========================
|
|
|
270
|
|
|
|
271
|
Every extension should use the ``testedwith`` variable to specify Mercurial
|
|
|
272
|
releases it's known to be compatible with. This helps us and users diagnose
|
|
|
273
|
where problems are coming from::
|
|
|
274
|
|
|
|
275
|
testedwith = '2.0 2.0.1 2.1 2.1.1 2.1.2'
|
|
|
276
|
|
|
|
277
|
Do not use the ``internal`` marker in third-party extensions; we will
|
|
|
278
|
immediately drop all bug reports mentioning your extension if we catch you
|
|
|
279
|
doing this.
|
|
|
280
|
|
|
|
281
|
Similarly, an extension can use the ``buglink`` variable to specify how users
|
|
|
282
|
should report issues with the extension. This link will be included in the
|
|
|
283
|
error message if the extension produces errors::
|
|
|
284
|
|
|
|
285
|
buglink = 'https://bitbucket.org/USER/REPO/issues'
|
|
|
286
|
|
|
|
287
|
Wrap up: what belongs where?
|
|
|
288
|
============================
|
|
|
289
|
|
|
|
290
|
You will find here a list of most common tasks, based on setups from the
|
|
|
291
|
extensions included in Mercurial core.
|
|
|
292
|
|
|
|
293
|
uisetup
|
|
|
294
|
-------
|
|
|
295
|
|
|
|
296
|
* Changes to ``ui.__class__`` . The ``ui`` object that will be used to run
|
|
|
297
|
the command has not yet been created. Changes made here will affect ``ui``
|
|
|
298
|
objects created after this, and in particular the ``ui`` that will be passed
|
|
|
299
|
to ``runcommand``
|
|
|
300
|
* Command wraps (``extensions.wrapcommand``)
|
|
|
301
|
* Changes that need to be visible by other extensions: because initialization
|
|
|
302
|
occurs in phases (all extensions run ``uisetup``, then all run ``extsetup``),
|
|
|
303
|
a change made here will be visible by other extensions during ``extsetup``.
|
|
|
304
|
* Monkeypatches or function wraps (``extensions.wrapfunction``) of ``dispatch``
|
|
|
305
|
module members
|
|
|
306
|
* Setup of ``pre-*`` and ``post-*`` hooks
|
|
|
307
|
* ``pushkey`` setup
|
|
|
308
|
|
|
|
309
|
extsetup
|
|
|
310
|
--------
|
|
|
311
|
|
|
|
312
|
* Changes depending on the status of other extensions. (``if extensions.find('mq')``)
|
|
|
313
|
* Add a global option to all commands
|
|
|
314
|
* Extend revsets
|
|
|
315
|
|
|
|
316
|
reposetup
|
|
|
317
|
---------
|
|
|
318
|
|
|
|
319
|
* All hooks but ``pre-*`` and ``post-*``
|
|
|
320
|
* Modify configuration variables
|
|
|
321
|
* Changes to ``repo.__class__``, ``repo.dirstate.__class__``
|