зеркало из https://github.com/mozilla/gecko-dev.git
c5ec5f3ef8
Now that we are gleaning a site packages source in a process-global way (that is *not* conditional on the site that's being managed), we've removed an edge case from occurring: the case where Mach would use `SitePackagesSource.NONE`, but the command site would use `SitePackagesSource.SYSTEM`. This would've occurred if none of Mach's dependencies were found in the system Python, but instead once the command site was initialized, one of *its* dependencies were located. Since that can no longer happen: * Command sites that don't populate their VENV will *always* use the same site packages source as Mach * `pthfile` generation is simplified (the priority of the system paths is no longer variable) * We no longer need to track `site_packages_source` in metadata, since we can use `mach_site_packages_source` instead. While here, I moved the "`PIP_NETWORK_INSTALL_RESTRICTED_VIRTUALENVS` sites shouldn't have `pypi_requirements`" check to a test, since there's no need for it to happen at runtime. Differential Revision: https://phabricator.services.mozilla.com/D140668 |
||
|---|---|---|
| .. | ||
| docs | ||
| mach | ||
| README.rst | ||
| bash-completion.sh | ||
| metrics.yaml | ||
| pings.yaml | ||
| setup.cfg | ||
| setup.py | ||
README.rst
==== mach ==== Mach (German for *do*) is a generic command dispatcher for the command line. To use mach, you install the mach core (a Python package), create an executable *driver* script (named whatever you want), and write mach commands. When the *driver* is executed, mach dispatches to the requested command handler automatically. To learn more, read the docs in ``docs/``.