3246.6.1
by Robert Collins
Add a plugin-api.txt developer document starting to description services for/from plugins. |
1 |
========== |
2 |
Plugin API |
|
3 |
========== |
|
4 |
||
5 |
Status |
|
6 |
====== |
|
7 |
||
8 |
:Date: 2008-02-29 |
|
9 |
||
10 |
bzrlib has a very flexible internal structure allowing plugins for many |
|
11 |
operations. Plugins can add commands, new storage formats, diff and merge |
|
3246.6.2
by Robert Collins
Review feedback. |
12 |
features and more. This document provides an overview of the API and |
13 |
conventions for plugin authors. |
|
3246.6.1
by Robert Collins
Add a plugin-api.txt developer document starting to description services for/from plugins. |
14 |
|
15 |
.. contents:: |
|
16 |
||
17 |
||
3246.6.2
by Robert Collins
Review feedback. |
18 |
Structure of a plugin |
19 |
===================== |
|
20 |
||
21 |
Plugins are Python modules under ``bzrlib.plugins``. They can be installed |
|
22 |
either into the PYTHONPATH in that location, or in ~/.bazaar/plugins. |
|
23 |
||
24 |
Plugins should have a setup.py. |
|
25 |
||
26 |
As for other Python modules, the name of the directory must match the |
|
27 |
expected name of the plugin. |
|
3246.6.1
by Robert Collins
Add a plugin-api.txt developer document starting to description services for/from plugins. |
28 |
|
29 |
||
30 |
Plugin metadata before installation |
|
31 |
=================================== |
|
32 |
||
33 |
Plugins can export a summary of what they provide, and what versions of bzrlib |
|
34 |
they are compatible with. This allows tools to be written to work with plugins, |
|
35 |
such as to generate a directory of plugins, or install them via a |
|
36 |
symlink/checkout to ~/.bazaar/plugins. |
|
37 |
||
3246.6.2
by Robert Collins
Review feedback. |
38 |
This interface allows bzr to interrogate a plugin without actually loading |
39 |
it. This is useful because loading a plugin may have side effects such |
|
40 |
as registering or overriding commands, or the plugin may raise an error, |
|
41 |
if for example a prerequisite is not present. |
|
3246.6.1
by Robert Collins
Add a plugin-api.txt developer document starting to description services for/from plugins. |
42 |
|
43 |
||
44 |
Metadata protocol |
|
45 |
----------------- |
|
46 |
||
47 |
A plugin that supports the bzr plugin metadata protocol will do two |
|
48 |
things. Firstly, the ``setup.py`` for the plugin will guard the call to |
|
49 |
``setup()``:: |
|
50 |
||
51 |
if __name__ == 'main': |
|
52 |
setup(...) |
|
53 |
||
54 |
Secondly, the setup module will have one or more of the following variables |
|
55 |
present at module scope. Any variables that are missing will be given the |
|
56 |
defaults from the table. An example of every variable is provided after |
|
57 |
the full list. |
|
58 |
||
59 |
+------------------------+---------+----------------------------------------+ |
|
60 |
| Variable | Default | Definition | |
|
61 |
+========================+=========+========================================+ |
|
62 |
| bzr_plugin_name | None | The name the plugin package should be | |
|
63 |
| | | given on disk. The plugin is then | |
|
64 |
| | | available to python at | |
|
65 |
| | | bzrlib.plugins.NAME | |
|
66 |
+------------------------+---------+----------------------------------------+ |
|
67 |
| bzr_commands | [] | A list of the commands that the plugin | |
|
68 |
| | | provides. Commands that already exist | |
|
69 |
| | | in bzr and are decorated by the plugin | |
|
70 |
| | | do not need to be listed (but it is not| |
|
71 |
| | | harmful if you do list them). | |
|
72 |
+------------------------+---------+----------------------------------------+ |
|
73 |
| bzr_plugin_version | None | A version_info 5-tuple with the plugins| |
|
74 |
| | | version. | |
|
75 |
+------------------------+---------+----------------------------------------+ |
|
76 |
| bzr_minimum_version | None | A version_info 3-tuple for comparison | |
|
77 |
| | | with the bzrlib minimum and current | |
|
78 |
| | | version, for determining likely | |
|
79 |
| | | compatibility. | |
|
80 |
+------------------------+---------+----------------------------------------+ |
|
81 |
| bzr_maximum_version | None | A version_info 3-tuple like | |
|
82 |
| | | bzr_minimum_version but checking the | |
|
83 |
| | | upper limits supported. | |
|
84 |
+------------------------+---------+----------------------------------------+ |
|
85 |
| bzr_control_formats | {} | A dictionary of descriptions of version| |
|
86 |
| | | control directories. See | |
|
87 |
| | | `Control Formats` below. | |
|
88 |
+------------------------+---------+----------------------------------------+ |
|
89 |
| bzr_checkout_formats | {} | A dictionary of tree_format_string -> | |
|
90 |
| | | human description strings, for tree | |
|
91 |
| | | formats that drop into the | |
|
92 |
| | | ``.bzr/checkout`` metadir system. | |
|
93 |
+------------------------+---------+----------------------------------------+ |
|
3246.6.3
by Robert Collins
Fix ReST table formatting in doc/developers/plugin-api.txt. |
94 |
| bzr_branch_formats | {} | As bzr_checkout_formats but for | |
95 |
| | | branches. | |
|
3246.6.1
by Robert Collins
Add a plugin-api.txt developer document starting to description services for/from plugins. |
96 |
+------------------------+---------+----------------------------------------+ |
3246.6.3
by Robert Collins
Fix ReST table formatting in doc/developers/plugin-api.txt. |
97 |
| bzr_repository_formats | {} | As bzr_checkout_formats but for | |
98 |
| | | repositories. | |
|
3246.6.1
by Robert Collins
Add a plugin-api.txt developer document starting to description services for/from plugins. |
99 |
+------------------------+---------+----------------------------------------+ |
100 |
||
101 |
Control Formats |
|
102 |
--------------- |
|
103 |
||
104 |
Because disk format detection for formats that bzr does not understand at |
|
3246.6.2
by Robert Collins
Review feedback. |
105 |
all can be useful, we allow a declarative description of the shape of a |
3246.6.1
by Robert Collins
Add a plugin-api.txt developer document starting to description services for/from plugins. |
106 |
control directory. Each description has a name for showing to users, and a |
107 |
dictonary of relative paths, and the content needed at each path. Paths |
|
108 |
that end in '/' are required to be directories and the value for that key |
|
109 |
is ignored. Other paths are required to be regular files, and the value |
|
110 |
for that key is either None, in which case the file is statted but the |
|
111 |
content is ignored, or a literal string which is compared against for |
|
112 |
the content of the file. Thus:: |
|
113 |
||
114 |
# (look for a .hg directory) |
|
115 |
bzr_control_formats = {"Mercurial":{'.hg/': None}} |
|
116 |
||
117 |
# (look for a file called .svn/format with contents 4\n). |
|
118 |
bzr_control_formats = {"Subversion":{'.svn/format': '4\n'}} |
|
119 |
||
120 |
||
121 |
Example |
|
122 |
------- |
|
123 |
||
124 |
An example setup.py follows:: |
|
125 |
||
126 |
#!/usr/bin/env python2.4 |
|
127 |
from distutils.core import setup |
|
128 |
||
129 |
bzr_plugin_name = 'demo' |
|
130 |
bzr_commands = [ |
|
131 |
'new-command', |
|
132 |
] |
|
133 |
||
134 |
bzr_branch_formats = { |
|
135 |
"Branch label on disk\n":"demo branch", |
|
136 |
} |
|
137 |
||
138 |
bzr_control_formats = {"Subversion":{'.svn/format': '4\n'}} |
|
139 |
||
140 |
bzr_plugin_version = (1, 3, 0, 'dev', 0) |
|
141 |
bzr_minimum_version = (1, 0, 0) |
|
142 |
||
143 |
if __name__ == 'main': |
|
144 |
setup(name="Demo", |
|
145 |
version="1.3.0dev0", |
|
146 |
description="Demo plugin for plugin metadata.", |
|
147 |
author="Canonical Ltd", |
|
148 |
author_email="bazaar@lists.canonical.com", |
|
149 |
license = "GNU GPL v2", |
|
150 |
url="https://launchpad.net/bzr-demo", |
|
151 |
packages=['bzrlib.plugins.demo', |
|
152 |
'bzrlib.plugins.demo.tests', |
|
153 |
], |
|
154 |
package_dir={'bzrlib.plugins.demo': '.'}) |
|
155 |
||
156 |
||
157 |
Plugin metadata after installation |
|
158 |
================================== |
|
159 |
||
160 |
After a plugin has been installed, metadata can be more easily obtained. |
|
161 |
Currently the only metadata used is for API versioning. |
|
162 |
||
163 |
API version |
|
164 |
----------- |
|
165 |
||
166 |
Please see `API versioning <api-versioning.html>`_ for details on the API |
|
167 |
metadata protocol used by bzrlib. |
|
168 |
||
169 |
||
170 |
.. |
|
171 |
vim: ft=rst tw=74 ai |
|
172 |
||
173 |