New issue
Advanced search Search tips

Issue 920340 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 801339


Show other hotlists

Hotlists containing this issue:
chrome-client-infra-backlog


Sign in to add a comment

Chrome build unexpectedly uses local site-packages "jinja2", wrong pythonpath?

Project Member Reported by klausw@chromium.org, Jan 9

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/.
 

Comment 1 Deleted

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".
Blockedon: 801339
Status: Available (was: Untriaged)
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.
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