зеркало из https://github.com/mozilla/gecko-dev.git
262077ed01
Previously we were tighly coupled with MozbuildObject. This was not in the spirit of mach being a generic tool. Now, instead of passing multiple arguments to __init__ of the class providing the mach command we either pass 0 or 1. The number of arguments is detected when processing the @CommandProvider decorator. The optional argument is a named tuple containing mach run-time state. Capturing of mach command provider information is now captured in a class (as opposed to an anoymous tuple). We also capture these in a rich data structure which is passed as part of the run-time data to the command provider class. This allows mach commands to inspect the mach environment. Mach decorators have been moved to mach.decorators. mach.base is reserved for generic mach data/container classes. Existing mach command classes derived from MozbuildObject have been replaced with either object or mozbuild.base.MachCommandBase. This latter class translates the mach context instance passed to __init__ into the constructor arguments for MozbuildObject.__init__. Support for registering function handlers with mach has been removed. All handlers must be inside classes. --HG-- rename : python/mach/mach/base.py => python/mach/mach/decorators.py |
||
---|---|---|
.. | ||
blessings | ||
mach | ||
mozboot | ||
mozbuild | ||
psutil | ||
simplejson-2.1.1 | ||
virtualenv | ||
which | ||
README |
README
This directory contains common Python code. The basic rule is that if Python code is cross-module (that's "module" in the Mozilla meaning - as in "module ownership") and is MPL-compatible, it should go here. What should not go here: * Python that is not MPL-compatible (see other-licenses/) * Python that has good reason to remain close to its "owning" (Mozilla) module (e.g. it is only being consumed from there). Historical information can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=775243