bzr branch
http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar
| 
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  |