зеркало из https://github.com/mozilla/gecko-dev.git
725792bd05
The existing terminology had two issues: * `VirtualenvManager` wasn't always associated with an on-disk `virtualenv`: for example, when running in automation, Mach "activates" a `VirtualenvManager`, updating its import scope, but without ever creating an on-disk `virtualenv`. * An upcoming patch splits the `VirtualenvManager` class, pulling "on-disk virtualenv-handling functions" from the project-wide interface for managing Python's import scope. After some good discussion with Ahal, I think we've struck the terminology that handles this distinction well: we'll call the "import scope"-handling part the "site", and we'll continue to call on-disk virtualenvs (and their representative classes) as, well, virtualenvs. Differential Revision: https://phabricator.services.mozilla.com/D130391 |
||
---|---|---|
.. | ||
mozbuild | ||
build-overview.rst | ||
build-targets.rst | ||
chrome-registration.rst | ||
cppeclipse.rst | ||
cross-compile.rst | ||
defining-binaries.rst | ||
defining-xpcom-components.rst | ||
environment-variables.rst | ||
files-metadata.rst | ||
glossary.rst | ||
gn.rst | ||
index.rst | ||
jar-manifests.rst | ||
locales.rst | ||
mozbuild-files.rst | ||
mozbuild-symbols.rst | ||
mozconfigs.rst | ||
mozinfo.rst | ||
pgo.rst | ||
preprocessor.rst | ||
python.rst | ||
rust.rst | ||
sccache-dist.rst | ||
slow.rst | ||
sparse.rst | ||
supported-configurations.rst | ||
telemetry.rst | ||
test_certificates.rst | ||
test_manifests.rst | ||
toolchains.rst | ||
unified-builds.rst | ||
visualstudio.rst |