зеркало из https://github.com/mozilla/gecko-dev.git
1ba4a4ea2d
* Restructure "Using third-party Python packages" page to focus on the "Mach commands"/"adding a Python package" use case since that's why most people will be looking at these docs. * Document the `<site>_virtualenv_packages.txt` behaviour and how it relates to a Mach command's definition. * Simplify the information around using a non-PyPI index to reference the RelEng docs directly. It's a shame that the existing docs don't explain how to identify tasks that need to use the internal mirror, because I'm not sure either. There's existing cases of ad-hoc `pip` installs //not// using the mirror, but the pattern isn't clear to me. * Remove the "specify hashes" information, since the centralized solution (will) automatically manage this internally. * Arguably, it's still beneficial instructions for ad-hoc `pip install` usages, but those are frowned upon today anyways - use the centralized solution! Differential Revision: https://phabricator.services.mozilla.com/D138931 |
||
|---|---|---|
| .. | ||
| devtools/migrate-l10n | ||
| docs | ||
| gdbpp/gdbpp | ||
| l10n | ||
| lldbutils | ||
| mach | ||
| mozboot | ||
| mozbuild | ||
| mozlint | ||
| mozperftest | ||
| mozrelease | ||
| mozterm | ||
| mozversioncontrol | ||
| README | ||
| mach_commands.py | ||
| moz.build | ||
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: * Vendored python modules (use third_party/python instead) * 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1346025