mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-24 21:31:04 +00:00
af1de54c49
We want `_pthfile_lines()` to consistently and accurately represent a virtualenv's `sys.path` modifications. However, this becomes tricky when comparing expected `pthfile_lines` //before// activating a virtualenv versus //afterwards//, especially since Python implicitly adds some paths (such as the path to `site-packages`). The current solution made this scrubbing only happen if we were `pip install`-ing into the site. Unfortunately, it //doesn't// work for the "use system Python for the `build` site", because: * Pre-activation result: `site-packages` isn't added, because we aren't using it * Post-activation result, implicitly-added `site-packages` isn't scrubbed, because **scrubbing only happened for `SitePackagesSource.VENV`** Stepping back, the solution here is: * `pthfile_lines` only represents Mach modifications //on top// of implicit virtualenv behaviour: since `site-packages` is always added by default, it shouldn't be in our explicit `pthfile_lines`. * The only time when implicit `sys.path` additions throws us off is when `SitePackagesSource.SYSTEM`: so, move the scrubbing to happen in that case instead. Finally refactor the "conditional deprioritization" comment to be more useful and more accurate: we've implemented the "nontrivial complexity" of purging site-packages, and the other piece about nothing being `pip install`-ed feels self-explanatory enough. Differential Revision: https://phabricator.services.mozilla.com/D140580 |
||
|---|---|---|
| .. | ||
| devtools/migrate-l10n | ||
| docs | ||
| gdbpp/gdbpp | ||
| l10n | ||
| lldbutils | ||
| mach | ||
| mozboot | ||
| mozbuild | ||
| mozlint | ||
| mozperftest | ||
| mozrelease | ||
| mozterm | ||
| mozversioncontrol | ||
| 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