~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/plugin-api.txt

  • Committer: John Arbash Meinel
  • Date: 2008-10-04 14:10:13 UTC
  • mto: This revision was merged to the branch mainline in revision 3805.
  • Revision ID: john@arbash-meinel.com-20081004141013-yskxjlwtuy2k18ue
Playing around with expanding requests for btree index nodes into neighboring nodes.

Show diffs side-by-side

added added

removed removed

Lines of Context:
2
2
Plugin API
3
3
==========
4
4
 
5
 
 
6
 
 
7
 
:Date: 2009-01-23
8
 
 
9
 
.. contents::
10
 
 
11
 
Introduction
12
 
============
 
5
Status
 
6
======
 
7
 
 
8
:Date: 2008-02-29
13
9
 
14
10
bzrlib has a very flexible internal structure allowing plugins for many
15
11
operations. Plugins can add commands, new storage formats, diff and merge
16
12
features and more. This document provides an overview of the API and
17
13
conventions for plugin authors.
18
14
 
19
 
If you're writing a plugin and have questions not addressed by this
20
 
document, please ask us.
21
 
 
22
 
See also
23
 
--------
24
 
 
25
 
 * `Bazaar Developer Documentation Catalog <../index.html>`_.
26
 
 * `Bazaar Plugins Guide <http://doc.bazaar.canonical.com/plugins/en/plugin-development.html>`_ for
27
 
   more suggestions about particular APIs.
 
15
.. contents::
28
16
 
29
17
 
30
18
Structure of a plugin
109
97
| bzr_repository_formats | {}      | As bzr_checkout_formats but for        |
110
98
|                        |         | repositories.                          |
111
99
+------------------------+---------+----------------------------------------+
112
 
| bzr_transports         | []      | URL prefixes for which this plugin     |
113
 
|                        |         | will register transports.              |
114
 
+------------------------+---------+----------------------------------------+
115
100
 
116
101
Control Formats
117
102
---------------
128
113
 
129
114
  # (look for a .hg directory)
130
115
  bzr_control_formats = {"Mercurial":{'.hg/': None}}
131
 
 
 
116
  
132
117
  # (look for a file called .svn/format with contents 4\n).
133
118
  bzr_control_formats = {"Subversion":{'.svn/format': '4\n'}}
134
119
 
137
122
-------
138
123
 
139
124
An example setup.py follows::
140
 
 
 
125
  
141
126
  #!/usr/bin/env python2.4
142
127
  from distutils.core import setup
143
 
 
 
128
  
144
129
  bzr_plugin_name = 'demo'
145
130
  bzr_commands = [
146
131
      'new-command',
147
132
      ]
148
 
 
 
133
  
149
134
  bzr_branch_formats = {
150
135
      "Branch label on disk\n":"demo branch",
151
136
      }
152
137
 
153
138
  bzr_control_formats = {"Subversion":{'.svn/format': '4\n'}}
154
 
 
155
 
  bzr_transports = ["hg+ssh://"]
156
 
 
 
139
  
157
140
  bzr_plugin_version = (1, 3, 0, 'dev', 0)
158
141
  bzr_minimum_version = (1, 0, 0)
159
 
 
 
142
  
160
143
  if __name__ == 'main':
161
144
      setup(name="Demo",
162
145
            version="1.3.0dev0",
174
157
Plugin metadata after installation
175
158
==================================
176
159
 
177
 
After a plugin has been installed, metadata can be more easily obtained by
178
 
looking inside the module object -- in other words, for variables defined
179
 
in the plugin's ``__init__.py``.
180
 
 
181
 
Help and documentation
182
 
----------------------
183
 
 
184
 
The module docstring is used as the plugin description shown by ``bzr
185
 
plugins``.  As with all Python docstrings, the first line should be a
186
 
short complete sentence summarizing the plugin.  The full docstring is
187
 
shown by ``bzr help PLUGIN_NAME``.
188
 
 
189
 
This is a user-visible docstring so should be prefixed with ``__doc__ =``
190
 
to ensure help works under ``python -OO`` with docstrings stripped.
 
160
After a plugin has been installed, metadata can be more easily obtained.
 
161
Currently the only metadata used is for API versioning.
191
162
 
192
163
API version
193
164
-----------
194
165
 
195
 
Plugins can and should declare that they depend on a particular version of
196
 
bzrlib like so::
197
 
 
198
 
    from bzrlib.api import require_api
199
 
 
200
 
    require_api(bzrlib, (1, 11, 0))
201
 
 
202
 
Please see `API versioning <api-versioning.html>`_ for more details on the API
 
166
Please see `API versioning <api-versioning.html>`_ for details on the API
203
167
metadata protocol used by bzrlib.
204
168
 
205
 
Plugin version
206
 
--------------
207
 
 
208
 
The plugin should expose a version tuple to describe its own version.
209
 
Some plugins use a version number that corresponds to the version of bzr
210
 
they're released against, but you can use whatever you want.  For example::
211
 
 
212
 
    version_info = (1, 10, 0)
213
 
 
214
 
 
215
 
Detecting whether code's being loaded as a plugin
216
 
-------------------------------------------------
217
 
 
218
 
You may have a Python module that can be used as a bzr plugin and also in
219
 
other places.  To detect whether the module is being loaded by bzr, use
220
 
something like this::
221
 
 
222
 
    if __name__ == 'bzrlib.plugins.loggerhead':
223
 
        # register with bzrlib...
224
 
 
225
 
 
226
 
Plugin performance
227
 
==================
228
 
 
229
 
Plugins should avoid doing work or loading code from the plugin or
230
 
external libraries, if they're just installed but not actually active,
231
 
because this slows down every invocation of bzr.  The bzrlib APIs
232
 
generally allow the plugin to 'lazily' register methods to invoke if a
233
 
particular disk format or seen or a particular command is run.
234
 
 
235
 
 
236
 
Plugin registrations
237
 
====================
238
 
 
239
 
The plugin ``__init__.py`` runs when the plugin is loaded during bzr
240
 
startup.  Generally the plugin won't want to actually do anything at this
241
 
time other than register or override functions to be called later.
242
 
 
243
 
The plugin can import bzrlib and call any function.
244
 
Some interesting APIs are described in `Bazaar Plugins Guide <http://doc.bazaar.canonical.com/plugins/en/plugin-development.html>`_.
245
 
 
246
 
 
247
 
Publishing your plugin
248
 
======================
249
 
 
250
 
When your plugin is basically working you might like to share it with
251
 
other people.  Here are some steps to consider:
252
 
 
253
 
 * make a project on Launchpad.net like
254
 
   <https://launchpad.net/bzr-fastimport>
255
 
   and publish the branches or tarballs there
256
 
 
257
 
 * include the plugin in <http://wiki.bazaar.canonical.com/BzrPlugins>
258
 
 
259
 
 * post about it to the ``bazaar-announce`` list at ``lists.canonical.com``
260
169
 
261
170
..
262
 
   vim: ft=rst tw=74 ai shiftwidth=4
 
171
   vim: ft=rst tw=74 ai
 
172
 
 
173