Cannot run `./mach bootstrap` with Python 3.10 on macOS - FileNotFoundError: [Errno 2] No such file or directory: '~/.mozbuild/srcdirs/mozilla-unified-7d5ac9f8ea6d/_virtualenvs/mach/lib/python3.10/site-packages/mach.pth'
Categories
(Firefox Build System :: Bootstrap Configuration, defect)
Tracking
(Not tracked)
People
(Reporter: jlorenzo, Unassigned)
References
Details
Attachments
(5 obsolete files)
Symptoms
On Friday, I wanted to bootstrap my machine one more time but I kept getting this error:
created virtual environment CPython3.10.5.final.0-64 in 22ms
creator CPython3Posix(dest=~/.mozbuild/srcdirs/mozilla-unified-7d5ac9f8ea6d/_virtualenvs/mach, clear=False, no_vcs_ignore=False, global=False)
activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator
Traceback (most recent call last):
File "~/hg/mozilla-unified/./mach", line 96, in <module>
main(sys.argv[1:])
File "~/hg/mozilla-unified/./mach", line 88, in main
mach = check_and_get_mach(os.path.dirname(os.path.realpath(__file__)))
File "~/hg/mozilla-unified/./mach", line 35, in check_and_get_mach
return load_mach(dir_path, mach_path)
File "~/hg/mozilla-unified/./mach", line 21, in load_mach
return mach_initialize.initialize(dir_path)
File "~/hg/mozilla-unified/build/mach_initialize.py", line 153, in initialize
_activate_python_environment(
File "~/hg/mozilla-unified/build/mach_initialize.py", line 99, in _activate_python_environment
mach_environment.activate()
File "~/hg/mozilla-unified/python/mach/mach/site.py", line 359, in activate
self.ensure()
File "~/hg/mozilla-unified/python/mach/mach/site.py", line 346, in ensure
self._build()
File "~/hg/mozilla-unified/python/mach/mach/site.py", line 384, in _build
_create_venv_with_pthfile(
File "~/hg/mozilla-unified/python/mach/mach/site.py", line 1188, in _create_venv_with_pthfile
with open(os.path.join(platlib_site_packages_dir, PTH_FILENAME), "w") as f:
FileNotFoundError: [Errno 2] No such file or directory: '~/.mozbuild/srcdirs/mozilla-unified-7d5ac9f8ea6d/_virtualenvs/mach/lib/python3.10/site-packages/mach.pth'
That was odd to me because I did manage to get bootstrap
to work when I set up my new machine a few weeks ago. After deep diving into mach/site.py
, virtualenv
, python 3.9 vs python 3.10, and sysconfig
. I managed to get the bottom of it.
My config
- MacBook Pro arm64 (M1)
- macOS 12.4
- Python 3.10.5 installed via
brew
- Python 3.9.13 also installed via
brew
A regression introduced in Python 3.10
Luckily, I managed to get ./mach bootstrap
in a working state when I forced Python 3.9 in the shebang of mach[1]. diffoscope
showed a weird change in the directory layout depending on what Python version mach
uses to create a virtualenv. It turns out the site-packages
folder is located under:
mozilla-unified-7d5ac9f8ea6d/_virtualenvs/mach/opt/homebrew/lib/python3.10/site-packages/
instead ofmozilla-unified-7d5ac9f8ea6d/_virtualenvs/mach/lib/python3.10/site-packages
Note the extraneous opt/homebrew/
in the first path. Thus, something was introduced in Python 3.10. It's a matter of figuring out what 🤔
Why were sysconfig_paths
hardcoded?
I hooked a debugger at various points including this one[1]. It turns out the self.interpreter
gets different values, notably in sysconfig_paths
:
# Python 3.9
PythonInfo({
[...]
'sysconfig_paths': {
'purelib': '{base}/lib/python{py_version_short}/site-packages',
'platlib': '{platbase}/{platlibdir}/python{py_version_short}/site-packages',
'scripts': '{base}/bin',
'data': '{base}'
},
})
# Python 3.10
PythonInfo({
[...]
'sysconfig_paths': {
[...]
'purelib': '/opt/homebrew/lib/python{py_version_short}/site-packages',
'platlib': '/opt/homebrew/{platlibdir}/python{py_version_short}/site-packages',
'scripts': '/opt/homebrew/bin',
'data': '/opt/homebrew'
},
)
I was surprised to see all these hardcoded values! After debugging deeper and deeper, it turns out it's a change in the python library called sysconfig
. virtualenv
calls sysconfig.get_path()
[3] and the behavior of this function changed in Python 3.10. It now determines a preferred scheme used to provide different sysconfig_paths
depending on the type of system you're on. Details of such changes are greatly documented here[4]. The maintainer of the virtualenv
packages is aware of these details and made the necessary changes in [5], which shipped in virtualenv
20.10.0.
What is the right fix?
We're currently using virtualenv
20.7.2 which doesn't include the aforementioned path. Hence it should be a matter of bumping our vendored version. I'm on it!
[1] https://searchfox.org/mozilla-central/rev/aa7c30cd45a7a8bbd2c969a31302db8f575796e6/mach#1
[2] https://searchfox.org/mozilla-central/rev/aa7c30cd45a7a8bbd2c969a31302db8f575796e6/third_party/python/virtualenv/virtualenv/create/describe.py#37
[3] https://searchfox.org/mozilla-central/rev/aa7c30cd45a7a8bbd2c969a31302db8f575796e6/third_party/python/virtualenv/virtualenv/discovery/py_info.py#76
[4] https://bugs.python.org/issue45413
[5] https://github.com/pypa/virtualenv/commit/8da79db86d8a5c74d03667a40e64ff832076445e
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 1•2 years ago
|
||
Updated•2 years ago
|
Reporter | ||
Comment 2•2 years ago
|
||
I need to test this patch in try
, but I need the right access (bug 1776650). Linking to bug 1724465 to link virtualenv
upgrades one another.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Reporter | ||
Comment 3•2 years ago
|
||
Pushed by jlorenzo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/100ff469d56b Bump virtualenv from 20.7.2 to 20.15.0 in order to run `mach boostrap` on Python 3.10 under macOS r=jcristau
Comment 5•2 years ago
|
||
Backed out for causing mach failures on test_site_compatibility.py
- backout: https://hg.mozilla.org/integration/autoland/rev/abffb47f8d47bcf77d593462bca8e505055053c3
- push: https://treeherder.mozilla.org/jobs?repo=autoland&revision=100ff469d56b910c9949cd9eec0d8affe2ff8961
- failure log: https://treeherder.mozilla.org/logviewer?job_id=383028045&repo=autoland&lineNumber=723
[task 2022-06-30T14:19:44.984Z]
[task 2022-06-30T14:19:44.984Z] =============================== warnings summary ===============================
[task 2022-06-30T14:19:44.985Z] python/mach/mach/main.py:13
[task 2022-06-30T14:19:44.985Z] /builds/worker/checkouts/gecko/python/mach/mach/main.py:13: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
[task 2022-06-30T14:19:44.985Z] import imp
[task 2022-06-30T14:19:44.986Z]
[task 2022-06-30T14:19:44.986Z] -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
[task 2022-06-30T14:19:44.987Z] ======================== 9 passed, 1 warning in 25.47s =========================
[task 2022-06-30T14:19:44.987Z]
[task 2022-06-30T14:19:44.987Z]
[task 2022-06-30T14:19:44.987Z] Tests Completed: 100%|██████████| 10/10 [00:29<00:00, 6.27s/Test]
[task 2022-06-30T14:19:44.987Z]
[task 2022-06-30T14:19:44.988Z] /builds/worker/checkouts/gecko/python/mach/mach/test/test_site_compatibility.py
[task 2022-06-30T14:19:44.988Z] ============================= test session starts ==============================
[task 2022-06-30T14:19:44.988Z] platform linux -- Python 3.6.9, pytest-7.0.1, pluggy-1.0.0 -- /builds/worker/checkouts/gecko/obj-x86_64-pc-linux-gnu/_virtualenvs/python-test/bin/python
[task 2022-06-30T14:19:44.988Z] rootdir: /builds/worker/checkouts/gecko, configfile: config/mozunit/mozunit/pytest.ini
[task 2022-06-30T14:19:44.988Z] collecting ... collected 1 item
[task 2022-06-30T14:19:44.988Z]
[task 2022-06-30T14:19:44.989Z] python/mach/mach/test/test_site_compatibility.py::test_sites_compatible TEST-UNEXPECTED-FAIL
[task 2022-06-30T14:19:44.989Z]
[task 2022-06-30T14:19:44.989Z] =================================== FAILURES ===================================
[task 2022-06-30T14:19:44.989Z] ____________________________ test_sites_compatible _____________________________
[task 2022-06-30T14:19:44.989Z] python/mach/mach/test/test_site_compatibility.py:154: in test_sites_compatible
[task 2022-06-30T14:19:44.990Z] cwd=topsrcdir,
[task 2022-06-30T14:19:44.990Z] /usr/lib/python3.6/subprocess.py:311: in check_call
[task 2022-06-30T14:19:44.991Z] raise CalledProcessError(retcode, cmd)
[task 2022-06-30T14:19:44.991Z] E subprocess.CalledProcessError: Command '['/tmp/pytest-of-worker/pytest-0/test_sites_compatible0/env/bin/pip', 'install', '-r', '/tmp/pytest-of-worker/pytest-0/test_sites_compatible0/requirements.txt']' returned non-zero exit status 1.
[task 2022-06-30T14:19:44.991Z] ----------------------------- Captured stdout call -----------------------------
Reporter | ||
Comment 6•2 years ago
|
||
Reporter | ||
Comment 7•2 years ago
|
||
Reporter | ||
Comment 8•2 years ago
|
||
carrot has been unmaitained since 2010[1]. setuptool>=58 cannot install it (same error as previous commit)
Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Pushed by jlorenzo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c4534787d467 part 1: Bump jsmin to 3.0.0 to fix incompatibility with setuptools>=58 r=jcristau https://hg.mozilla.org/integration/autoland/rev/40cfebba22ac part 2: Stop installing 'carrot' in mach tests and use a more recent package instead r=jcristau https://hg.mozilla.org/integration/autoland/rev/450e42238ace part 3: Bump virtualenv from 20.7.2 to 20.15.0 in order to run `mach boostrap` on Python 3.10 under macOS r=jcristau
Comment 10•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c4534787d467
https://hg.mozilla.org/mozilla-central/rev/40cfebba22ac
https://hg.mozilla.org/mozilla-central/rev/450e42238ace
Comment 11•2 years ago
•
|
||
Backed out 3 changesets (Bug 1776642) for Pip version update causes CI tasks to fail (Bug 1780539).
Backout link
Reporter | ||
Comment 12•2 years ago
|
||
Status update: Bumping virtualenv
may not be the right way to go anymore, per bug 1779376 comment 4. It caused more problems than it solved, anyway. So the next approach would be to get rid of the virtualenv
package. I don't feel comfortable changing that important piece. I'm unassigning myself from this bug.
More info in bug 1779376 comment 5, bug 1779376 comment 6. Feel free to ping me if you need more context 🙂
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 13•2 years ago
|
||
Interesting, this never showed up in my triage queue since you assigned it to yourself (before eventually unassigning it).
The 'fix' of getting rid of virtualenv
was started by Mitch in Bug 1766497, but hasn't quite landed yet. There's some issue with Mozharness that I haven't quite resolved, but it's in my queue of things to do.
Reporter | ||
Comment 14•2 years ago
|
||
Wonderful! Thanks for taking this on 🙂
Description
•