gecko/python
Gregory Szorc b7addff074 Bug 1134072 - Support for sub-contexts; r=glandium
As content in moz.build files has grown, it has become clear that
storing everything in one global namespace (the "context") per moz.build
file will not scale. This approach (which is carried over from
Makefile.in patterns) limits our ability to do things like declare
multiple instances of things (like libraries) per file.

A few months ago, templates were introduced to moz.build files. These
started the process of introducing separate contexts / containers in
each moz.build file. But it stopped short of actually emitting multiple
contexts per container. Instead, results were merged with the main
context.

This patch takes sub-contexts to the next level.

Introduced is the "SubContext" class. It is a Context derived from
another context. SubContexts are special in that they are context
managers. With the context manager is entered, the SubContext becomes
the main context associated with the executing sandbox, temporarily
masking the existence of the main context. This means that UPPERCASE
variable accesses and writes will be handled by the active SubContext.
This allows SubContext instances to define different sets of variables.

When a SubContext is spawned, it is attached to the sandbox executing
it. The moz.build reader will now emit not only the main context, but
also every SubContext that was derived from it.

To aid with the creation and declaration of sub-contexts, we introduce
the SUBCONTEXTS variable. This variable holds a list of classes that
define sub-contexts.

Sub-contexts behave a lot like templates. Their class names becomes the
symbol name in the sandbox.
2015-02-24 13:05:59 -08:00
..
bitstring
blessings
configobj
eme Bug 1131798 - Fix handling of CPU sub-type and rebasing WITHOUT requiring Python 3.3. r=ted 2015-02-21 16:43:36 +13:00
jsmin
lldbutils Bug 1118228 - Add an lldb helper that allows calling functions without debug info. r=jrmuizel, r=ehsan 2015-01-14 19:04:24 -05:00
mach Bug 1129798 - Use pdb.runcall to debug mach commands; r=ahal 2015-02-04 22:49:06 -08:00
mock-1.0.0
mozboot Bug 1123824 - Include platforms/android-VERSION in suggested mozconfig. r=me,f=psd 2015-01-26 11:13:49 -08:00
mozbuild Bug 1134072 - Support for sub-contexts; r=glandium 2015-02-24 13:05:59 -08:00
mozversioncontrol/mozversioncontrol
psutil Backed out changeset 697eb6db7d96 (bug 930808) for OS X make check failures 2014-12-23 21:04:19 -08:00
pyasn1
pystache Bug 1068653 - Part 1 Add python dependencies for taskcluster mach commands r=gps 2014-11-26 10:11:28 -08:00
pyyaml Bug 1068653 - Part 1 Add python dependencies for taskcluster mach commands r=gps 2014-11-26 10:11:28 -08:00
redo Bug 1118774 - Import python redo library; r=gps 2015-01-07 14:18:20 -05:00
virtualenv Bug 1119350 - Upgrade virtualenv to 12.0.5; r=gps 2015-01-08 10:52:07 -07:00
which Bug 1119776, Part 7: Avoid defining snprintf when MSVC provides it (other), r=bsmedberg 2015-01-08 22:35:33 -08:00
mach_commands.py
moz.build NO BUG - Remove deleted python/codegen from Sphinx docs 2014-12-29 15:49:36 -08:00
README Bug 1068653 - Part 1 Add python dependencies for taskcluster mach commands r=gps 2014-11-26 10:11:28 -08:00

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

## pyyaml | pystache

Used in taskcluster related mach commands to update download from github
and remove .git and tests.

Then run tests in taskcluster/tests/