##// END OF EJS Templates
help: add internals.extensions topic...
Yuya Nishihara -
r40631:419d7031 default
parent child Browse files
Show More
@@ -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__``
@@ -47,6 +47,7 b''
47 47 <File Id="internals.censor.txt" Name="censor.txt" />
48 48 <File Id="internals.changegroups.txt" Name="changegroups.txt" />
49 49 <File Id="internals.config.txt" Name="config.txt" />
50 <File Id="internals.extensions.txt" Name="extensions.txt" />
50 51 <File Id="internals.linelog.txt" Name="linelog.txt" />
51 52 <File Id="internals.requirements.txt" Name="requirements.txt" />
52 53 <File Id="internals.revlogs.txt" Name="revlogs.txt" />
@@ -311,6 +311,8 b' internalstable = sorted(['
311 311 loaddoc('changegroups', subdir='internals')),
312 312 (['config'], _('Config Registrar'),
313 313 loaddoc('config', subdir='internals')),
314 (['extensions', 'extension'], _('Extension API'),
315 loaddoc('extensions', subdir='internals')),
314 316 (['requirements'], _('Repository Requirements'),
315 317 loaddoc('requirements', subdir='internals')),
316 318 (['revlogs'], _('Revision Logs'),
@@ -1066,6 +1066,7 b' internals topic renders index of availab'
1066 1066 censor Censor
1067 1067 changegroups Changegroups
1068 1068 config Config Registrar
1069 extensions Extension API
1069 1070 requirements Repository Requirements
1070 1071 revlogs Revision Logs
1071 1072 wireprotocol Wire Protocol
@@ -3404,6 +3405,13 b' Sub-topic indexes rendered properly'
3404 3405 Config Registrar
3405 3406 </td></tr>
3406 3407 <tr><td>
3408 <a href="/help/internals.extensions">
3409 extensions
3410 </a>
3411 </td><td>
3412 Extension API
3413 </td></tr>
3414 <tr><td>
3407 3415 <a href="/help/internals.requirements">
3408 3416 requirements
3409 3417 </a>
General Comments 0
You need to be logged in to leave comments. Login now