Chrome build unexpectedly uses local site-packages "jinja2", wrong pythonpath? |
||
Issue description
I was getting weird compile errors for ToT Chrome which turned out to be caused by invalid template expansion. Should the run_with_pythonpath script have prevented this?
According to strace, the make_css_property_subclasses.py script was using .local/lib/python2.7/site-packages/jinja2 from my home directory, which was version Jinja2-2.7.3.egg-info . That resulted in invalid template expansion, with a method-closing "}" erroneously appearing in the same line as the preceding "// intentionally left blank" comment.
Removing the jinja2 package from my home dir fixed this issue.
Is this an expected problem? I was assuming that the run_with_pythonpath wrapper would ensure that the files from the chromium src dir would be used by preference?
Here's the command that was run according to "ninja -v -v":
python ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I ../../third_party/blink/renderer/build/scripts -I ../../third_party ../../third_party/blink/renderer/build/scripts/core/css/properties/make_css_property_subclasses.py ../../third_party/blink/renderer/core/css/css_properties.json5 ../../third_party/blink/renderer/core/css/computed_style_field_aliases.json5 ../../third_party/blink/renderer/core/css/properties/css_property_methods.json5 --output_dir gen/third_party/blink/renderer/core/css/properties/longhands --gperf gperf
And the files/directories read according to strace:
$ egrep '(jinja2.pyc|jinja2/__init__)' strace.out
[pid 107803] open("/usr/local/google/home/klausw/chromium/src/third_party/blink/renderer/build/scripts/core/css/properties/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/lib/python2.7/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/lib/python2.7/plat-x86_64-linux-gnu/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/lib/python2.7/lib-tk/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/lib/python2.7/lib-dynload/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/local/google/home/klausw/.local/lib/python2.7/site-packages/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/local/lib/python2.7/dist-packages/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/lib/python2.7/dist-packages/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/lib/python2.7/dist-packages/PILcompat/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/lib/python2.7/dist-packages/gtk-2.0/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/local/google/home/klausw/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] open("/usr/local/google/home/klausw/chromium/src/third_party/blink/renderer/build/scripts/jinja2.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 107803] stat("/usr/local/google/home/klausw/chromium/src/third_party/jinja2/__init__.py", {st_mode=S_IFREG|0644, st_size=2614, ...}) = 0
This is from the fixed build, you can see that it's opening my local jinja2 with an ENOENT error, but if it exists it uses that ahead of third_party/jinja2/.
,
Jan 9
FYI, it appears that Python only checks .local/lib/python2.7/site-packages/jinja2.pyc if the site-packages directory exists. To reproduce, you may need to do a "mkdir -p $HOME/.local/lib/python2.7/site-packages".
,
Jan 9
Long term, IMHO we should eliminate run_with_pythonpath.py and similar wrapper scripts with vpython - issue 801339. If you'd like to convert to vpython sooner - you're very welcome to do so! For now, I'm making this available and adding to our tracking hotlist. Chances are, it'll become a WontFix once we migrate all python scripts to use vpython. Unfortunately, there is no ETA for this yet.
,
Jan 9
Thanks! I don't have any current plans to work on this for now, I just wanted to file a bug for reference in case someone else runs across this or similar issues. A standalone vpython environment for building that's isolated from the default Python environment sounds great. |
||
►
Sign in to add a comment |
||
Comment 1 Deleted