/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to HACKING

  • Committer: Robert Collins
  • Date: 2005-10-06 03:08:26 UTC
  • Revision ID: robertc@robertcollins.net-20051006030826-cfd416d323559cfa
update HACKING

Show diffs side-by-side

added added

removed removed

Lines of Context:
HACKING
 
1
============================
 
2
guidelines for modifying bzr
 
3
============================
 
4
 
 
5
* New functionality should have test cases.  Preferably write the
 
6
  test before writing the code.
 
7
 
 
8
  In general, you can test at either the command-line level or the
 
9
  internal API level.  Choose whichever is appropriate: if adding a
 
10
  new command, or a new command option, then call through run_bzr().
 
11
  It is not necessary to do both. Tests that test the command line level
 
12
  are appropriate for checking the UI behaves well - bug fixes and
 
13
  core improvements should be tested closer to the code that is doing the
 
14
  work. Command line level tests should be placed in 'blackbox.py'.
 
15
 
 
16
* Before fixing a bug, write a test case so that it does not regress.
 
17
 
 
18
* Exceptions should be defined inside bzrlib.errors, so that we can
 
19
  see the whole tree at a glance.
 
20
 
 
21
* Imports should be done at the top-level of the file, unless there is
 
22
  a strong reason to have them lazily loaded when a particular
 
23
  function runs.  Import statements have a cost, so try to make sure
 
24
  they don't run inside hot functions.
 
25
 
 
26
* Please write PEP-8__ compliant code.  
 
27
 
 
28
  One often-missed requirement is that the first line of docstrings
 
29
  should be a self-contained one-sentence summary.
 
30
 
 
31
__ http://www.python.org/peps/pep-0008.html
 
32
 
 
33
* Module names should always be given fully-qualified,
 
34
  i.e. ``bzrlib.hashcache`` not just ``hashcache``.
 
35
 
 
36
* If you change the behaviour of an API in an incompatible way, please
 
37
  be sure to change its name as well. For instance, if I add a keyword
 
38
  parameter to branch.commit - thats fine. On the other hand, if I add
 
39
  a keyword parameter to branch.commit which is a *required* transaction
 
40
  object, I should rename the api - i.e. to 'branch.commit_transaction'.
 
41
  This will prevent users of the old api outside of the tree getting
 
42
  surprising results. 
 
43
  Instead, they will get an Attribute error as the api is missing, and
 
44
  will know to update their code. If in doubt, just ask on #bzr.
 
45
 
 
46
 
 
47
Documentation
 
48
=============
 
49
 
 
50
If you change the behaviour of a command, please update its docstring
 
51
in bzrlib/commands.py.  This is displayed by the 'bzr help' command.
 
52
 
 
53
If you make a user-visible change, please add a note to the NEWS file.
 
54
The description should be written to make sense to someone who's just
 
55
a user of bzr, not a developer: new functions or classes shouldn't be
 
56
mentioned, but new commands, changes in behaviour or fixed nontrivial
 
57
bugs should be listed.  See the existing entries for an idea of what
 
58
should be done.
 
59
 
 
60
 
 
61
 
 
62
Writing output
 
63
==============
 
64
 
 
65
(The strategy described here is what we want to get to, but it's not
 
66
consistently followed in the code at the moment.)
 
67
 
 
68
bzrlib is intended to be a generically reusable library.  It shouldn't
 
69
write messages to stdout or stderr, because some programs that use it
 
70
might want to display that information through a GUI or some other
 
71
mechanism.
 
72
 
 
73
We can distinguish two types of output from the library:
 
74
 
 
75
 1. Structured data representing the progress or result of an
 
76
    operation.  For example, for a commit command this will be a list
 
77
    of the modified files and the finally committed revision number
 
78
    and id.
 
79
 
 
80
    These should be exposed either through the return code or by calls
 
81
    to a callback parameter.
 
82
 
 
83
    A special case of this is progress indicators for long-lived
 
84
    operations, where the caller should pass a ProgressBar object.
 
85
 
 
86
 2. Unstructured log/debug messages, mostly for the benefit of the
 
87
    developers or users trying to debug problems.  This should always
 
88
    be sent through ``bzrlib.trace`` and Python ``logging``, so that
 
89
    it can be redirected by the client.
 
90
 
 
91
The distinction between the two is a bit subjective, but in general if
 
92
there is any chance that a library would want to see something as
 
93
structured data, we should make it so.
 
94
 
 
95
The policy about how output is presented in the text-mode client
 
96
should be only in the command-line tool.
 
97
 
 
98
Writing tests
 
99
=============
 
100
In general tests should be placed in a file named test_FOO.py where 
 
101
FOO is the logical thing under test. That file should be placed in the
 
102
tests subdirectory under the package being tested.
 
103
 
 
104
For example, tests for merge3 in bzrlib belong in bzrlib/tests/test_merge3.py.
 
105
 
 
106
Running tests
 
107
=============
 
108
Currently, bzr selftest is used to invoke tests.
 
109
You can provide a pattern argument to run a subset. For example, 
 
110
to run just the whitebox tests, run bzr selftest --pattern .*whitebox.*
 
111