gecko-dev/python
Gregory Szorc cc764ee794 Bug 1315785 - Set an environment variable when mach is attached to a TTY; r=glandium
The way it works now, `mach` commands often invoke subprocesses where
the subprocesses' stdio file descriptors are pipes so the mach command
can e.g. parse output.

Processes like clang, gcc, and cargo determine if they can send color
codes to {stderr, stdout} by seeing if those file descriptors are TTYs.
When e.g. `make` is executed via `mach`, this test fails because those
descriptors are pipes (even though they eventually end up on a TTY).

We can't wire the file descriptors to the TTY because `mach` needs
to analyze output. We don't want users defining process flags to force
color in their mozconfigs because color codes would still be sent
if stdout was not a TTY.

This patch sets the MACH_STDOUT_ISATTY environment variable in all mach
commands when stdout is a TTY. Subsequent processes can then look for
this variable to determine whether to override color settings, print
terminal control codes, etc.

MozReview-Commit-ID: GxXP2mQssjC

--HG--
extra : rebase_source : 4b99547b453cb7dd5cb590a71ed554ce2bc4759d
2016-11-08 12:15:13 -08:00
..
PyECC
altgraph
bitstring
blessings
compare-locales bug 1291275, sys.stdout is utf-8 in mach, don't double-encode, r=glandium 2016-08-29 15:07:19 +02:00
configobj
devtools/migrate-l10n Bug 1312333 - Include bug1309191 in devtools l10n migration script for NetMonitor. r=pike 2016-10-23 23:19:00 +02:00
eme
futures
gdbpp/gdbpp Bug 1304302 part 11 - Remove StyleSheetHandle as well as other places reference it. r=heycam 2016-09-26 22:03:25 +10:00
jsmin
lldbutils
mach Bug 1315785 - Set an environment variable when mach is attached to a TTY; r=glandium 2016-11-08 12:15:13 -08:00
macholib
mock-1.0.0
mozboot Bug 1313379 - Fix mach bootstrap for Windows desktop artifact mode. r=gps 2016-10-28 21:45:43 -07:00
mozbuild Merge m-i to m-c, a=merge 2016-11-02 19:28:38 -07:00
mozlint Bug 1315805 - [mozlint] Make sure multiprocess' stdout gets flushed in lint tasks, r=dustin 2016-11-08 13:33:13 -05:00
mozversioncontrol/mozversioncontrol bug 1294565 - add some more helpers to mozversioncontrol, add MozbuildObject.repository. r=gps 2016-09-29 06:48:37 -04:00
psutil
py Bug 1253359 - Vendor in Pytest 2.9.2 and Py 1.4.31 r=gps 2016-08-10 13:34:59 +02:00
pyasn1
pyasn1-modules
pylru Bug 1100925 - Vendored pylru 1.0.9 into mozilla-central. r=gps 2016-07-13 14:22:01 -07:00
pystache
pytest Bug 1253359 - Vendor in Pytest 2.9.2 and Py 1.4.31 r=gps 2016-08-10 13:34:59 +02:00
pytoml Bug 1231764 - part 4 - add pytoml to the virtualenv; r=chmanchester 2016-08-06 00:49:26 -04:00
pyyaml
redo Bug 1301785: update python/redo to 1.6; r=gps 2016-10-31 15:41:28 +00:00
requests
rsa
slugid
virtualenv Bug 1295439 - Upgrade setuptools to 25.2.0; r=glandium 2016-08-16 08:46:57 -07:00
voluptuous Bug 1281004: vendor voluptuous; r=gps 2016-06-29 20:39:02 +00:00
which
README
mach_commands.py Bug 1253359 - Use vendored Pytest in `python-test` and Mn harness tests r=gps 2016-08-05 20:10:09 +02:00
moz.build Bug 1313306 - Move --help dependency checks to the linter. r=chmanchester 2016-10-27 10:02:21 +09:00

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

## pyyaml | pystache

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

Then run tests in taskcluster/tests/