========================= Interacting with the user ========================= Getting Input ============= Processing Command Lines ------------------------ bzrlib has a standard framework for parsing command lines and calling processing routines associated with various commands. See builtins.py for numerous examples. Standard Parameter Types ------------------------ There are some common requirements in the library: some parameters need to be unicode safe, some need byte strings, and so on. At the moment we have only codified one specific pattern: Parameters that need to be unicode should be checked via ``bzrlib.osutils.safe_unicode``. This will coerce the input into unicode in a consistent fashion, allowing trivial strings to be used for programmer convenience, but not performing unpredictably in the presence of different locales. Confirmation ------------ There are some operations, such as uncommitting, or breaking a lock, where bzr may want to get confirmation from the user before proceeding. However in some circumstances bzr should just go ahead without asking: if it's being used from a noninteractive program, or if the user's asked to never be asked for this particular confirmation or for any confirmations at all. We provide a special UIFactory method `confirm_action` to do this. It takes a `confirmation_id` parameter that acts as a symbolic name for the type of confirmation, so the user can configure them off. (This is not implemented at present.) Confirmation ids look like Python paths to the logical code that should use them. (Because code may move or the check may for implementation reasons be done elsewhere, they need not perfectly correspond to the place they're used, and they should stay stable even when the code moves.) ``bzrlib.lockdir.break`` Before breaking a lock. ``bzrlib.builtins.uncommit`` Before the ``uncommit`` command actually changes the branch. Writing Output ============== (The strategy described here is what we want to get to, but it's not consistently followed in the code at the moment.) bzrlib is intended to be a generically reusable library. It shouldn't write messages to stdout or stderr, because some programs that use it might want to display that information through a GUI or some other mechanism. We can distinguish two types of output from the library: 1. Structured data representing the progress or result of an operation. For example, for a commit command this will be a list of the modified files and the finally committed revision number and id. These should be exposed either through the return code or by calls to a callback parameter. A special case of this is progress indicators for long-lived operations, where the caller should pass a ProgressBar object. 2. Unstructured log/debug messages, mostly for the benefit of the developers or users trying to debug problems. This should always be sent through ``bzrlib.trace`` and Python ``logging``, so that it can be redirected by the client. The distinction between the two is a bit subjective, but in general if there is any chance that a library would want to see something as structured data, we should make it so. The policy about how output is presented in the text-mode client should be only in the command-line tool. Progress and Activity Indications --------------------------------- bzrlib has a way for code to display to the user that stuff is happening during a long operation. There are two particular types: *activity* which means that IO is happening on a Transport, and *progress* which means that higher-level application work is occurring. Both are drawn together by the `ui_factory`. Transport objects are responsible for calling `report_transport_activity` when they do IO. Progress uses a model/view pattern: application code acts on a `ProgressTask` object, which notifies the UI when it needs to be displayed. Progress tasks form a stack. To create a new progress task on top of the stack, call `bzrlib.ui.ui_factory.nested_progress_bar()`, then call `update()` on the returned ProgressTask. It can be updated with just a text description, with a numeric count, or with a numeric count and expected total count. If an expected total count is provided the view can show the progress moving along towards the expected total. The user should call `finish` on the `ProgressTask` when the logical operation has finished, so it can be removed from the stack. Progress tasks have a complex relationship with generators: it's a very good place to use them, but because python2.4 does not allow ``finally`` blocks in generators it's hard to clean them up properly. In this case it's probably better to have the code calling the generator allocate a progress task for its use and then call `finalize` when it's done, which will close it if it was not already closed. The generator should also finish the progress task when it exits, because it may otherwise be a long time until the finally block runs. Message guidelines ------------------ When filenames or similar variables are presented inline within a message, they should be enclosed in double quotes (ascii 0x22, not chiral unicode quotes):: bzr: ERROR: No such file "asdf" When we print just a list of filenames there should not be any quoting: see `bug 544297`_. .. _bug 544297: https://bugs.launchpad.net/bugs/544297 https://wiki.ubuntu.com/UnitsPolicy provides a good explanation about which unit should be used when. Roughly speaking, IEC standard applies for base-2 units and SI standard applies for base-10 units: * for network bandwidth and disk sizes, use base-10 (Mbits/s, kB/s, GB) * for RAM sizes, use base-2 (GiB, TiB) Displaying help =============== Bazaar has online help for various topics through ``bzr help COMMAND`` or equivalently ``bzr command -h``. We also have help on command options, and on other help topics. (See ``help_topics.py``.) As for python docstrings, the first paragraph should be a single-sentence synopsis of the command. These are user-visible and should be prefixed with ``__doc__ =`` so help works under ``python -OO`` with docstrings stripped. The help for options should be one or more proper sentences, starting with a capital letter and finishing with a full stop (period). All help messages and documentation should have two spaces between sentences. Handling Errors and Exceptions ============================== Commands should return non-zero when they encounter circumstances that the user should really pay attention to - which includes trivial shell pipelines. Recommended values are: 0. OK. 1. Conflicts in merge-like operations, or changes are present in diff-like operations. 2. Unrepresentable diff changes (i.e. binary files that we cannot show a diff of). 3. An error or exception has occurred. 4. An internal error occurred (one that shows a traceback.) Errors are handled through Python exceptions. Exceptions should be defined inside bzrlib.errors, so that we can see the whole tree at a glance. We broadly classify errors as either being either internal or not, depending on whether ``internal_error`` is set or not. If we think it's our fault, we show a backtrace, an invitation to report the bug, and possibly other details. This is the default for errors that aren't specifically recognized as being caused by a user error. Otherwise we show a briefer message, unless -Derror was given. Many errors originate as "environmental errors" which are raised by Python or builtin libraries -- for example IOError. These are treated as being our fault, unless they're caught in a particular tight scope where we know that they indicate a user errors. For example if the repository format is not found, the user probably gave the wrong path or URL. But if one of the files inside the repository is not found, then it's our fault -- either there's a bug in bzr, or something complicated has gone wrong in the environment that means one internal file was deleted. Many errors are defined in ``bzrlib/errors.py`` but it's OK for new errors to be added near the place where they are used. Exceptions are formatted for the user by conversion to a string (eventually calling their ``__str__`` method.) As a convenience the ``._fmt`` member can be used as a template which will be mapped to the error's instance dict. New exception classes should be defined when callers might want to catch that exception specifically, or when it needs a substantially different format string. #. If it is something that a caller can recover from, a custom exception is reasonable. #. If it is a data consistency issue, using a builtin like ``ValueError``/``TypeError`` is reasonable. #. If it is a programmer error (using an api incorrectly) ``AssertionError`` is reasonable. #. Otherwise, use ``BzrError`` or ``InternalBzrError``. Exception strings should start with a capital letter and should not have a final fullstop. If long, they may contain newlines to break the text.