~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to HACKING

  • Committer: Martin Pool
  • Date: 2005-08-23 00:40:27 UTC
  • Revision ID: mbp@sourcefrog.net-20050823004027-e6e45a392f540bb4
todo

Show diffs side-by-side

added added

removed removed

Lines of Context:
20
20
  function runs.  Import statements have a cost, so try to make sure
21
21
  they don't run inside hot functions.
22
22
 
23
 
* Please write PEP-8__ compliant code.  
24
 
 
25
 
  One often-missed requirement is that the first line of docstrings
26
 
  should be a self-contained one-sentence summary.
 
23
* Please write PEP-8__ compliant code.
27
24
 
28
25
__ http://www.python.org/peps/pep-0008.html
29
26
 
44
41
mentioned, but new commands, changes in behaviour or fixed nontrivial
45
42
bugs should be listed.  See the existing entries for an idea of what
46
43
should be done.
47
 
 
48
 
 
49
 
 
50
 
Writing output
51
 
==============
52
 
 
53
 
(The strategy described here is what we want to get to, but it's not
54
 
consistently followed in the code at the moment.)
55
 
 
56
 
bzrlib is intended to be a generically reusable library.  It shouldn't
57
 
write messages to stdout or stderr, because some programs that use it
58
 
might want to display that information through a GUI or some other
59
 
mechanism.
60
 
 
61
 
We can distinguish two types of output from the library:
62
 
 
63
 
 1. Structured data representing the progress or result of an
64
 
    operation.  For example, for a commit command this will be a list
65
 
    of the modified files and the finally committed revision number
66
 
    and id.
67
 
 
68
 
    These should be exposed either through the return code or by calls
69
 
    to a callback parameter.
70
 
 
71
 
    A special case of this is progress indicators for long-lived
72
 
    operations, where the caller should pass a ProgressBar object.
73
 
 
74
 
 2. Unstructured log/debug messages, mostly for the benefit of the
75
 
    developers or users trying to debug problems.  This should always
76
 
    be sent through ``bzrlib.trace`` and Python ``logging``, so that
77
 
    it can be redirected by the client.
78
 
 
79
 
The distinction between the two is a bit subjective, but in general if
80
 
there is any chance that a library would want to see something as
81
 
structured data, we should make it so.
82
 
 
83
 
The policy about how output is presented in the text-mode client
84
 
should be only in the command-line tool.
85
 
 
86
 
Writing tests
87
 
=============
88
 
In general tests should be placed in a file named test_FOO.py where 
89
 
FOO is the logical thing under test. That file should be placed in the
90
 
tests subdirectory under the package being tested.
91
 
 
92
 
For example, tests for merge3 in bzrlib belong in bzrlib/tests/test_merge3.py.
93
 
 
94
 
Running tests
95
 
=============
96
 
Currently, bzr selftest is used to invoke tests.
97
 
You can provide a pattern argument to run a subset. For example, 
98
 
to run just the whitebox tests, run bzr selftest --pattern .*whitebox.*
99