← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to HACKING

  • Committer: Martin Pool
  • Date: 2005-08-24 08:59:32 UTC
  • Revision ID: mbp@sourcefrog.net-20050824085932-c61f1f1f1c930e13
- Add a simple UIFactory 

  The idea of this is to let a client of bzrlib set some 
  policy about how output is displayed.

  In this revision all that's done is that progress bars
  are constructed by a policy established by the application
  rather than being randomly constructed in the library 
  or passed down the calls.  This avoids progress bars
  popping up while running the test suite and cleans up
  some code.

Show diffs side-by-side

added added

removed removed

Lines of Context:
HACKING
 
1
============================
1
2
guidelines for modifying bzr
2
3
============================
3
4
 
19
20
  function runs.  Import statements have a cost, so try to make sure
20
21
  they don't run inside hot functions.
21
22
 
22
 
* Please write PEP-8__ compliant code.
 
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
27
 
24
28
__ http://www.python.org/peps/pep-0008.html
25
29
 
26
30
* Module names should always be given fully-qualified,
27
 
  i.e. ``bzrlib.hashcache`` not just ``hashcache``.
 
 
b'\\ No newline at end of file'
 
31
  i.e. ``bzrlib.hashcache`` not just ``hashcache``.
 
32
 
 
33
 
 
34
 
 
35
Documentation
 
36
=============
 
37
 
 
38
If you change the behaviour of a command, please update its docstring
 
39
in bzrlib/commands.py.  This is displayed by the 'bzr help' command.
 
40
 
 
41
If you make a user-visible change, please add a note to the NEWS file.
 
42
The description should be written to make sense to someone who's just
 
43
a user of bzr, not a developer: new functions or classes shouldn't be
 
44
mentioned, but new commands, changes in behaviour or fixed nontrivial
 
45
bugs should be listed.  See the existing entries for an idea of what
 
46
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.