-
-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compileall.compile_dir(..., ddir="<prefix>") omits the intermediate package paths when prepending the prefix #83950
Comments
Easiest to demonstrate as such: #!/bin/bash
mkdir bug
touch bug/__init__.py
mkdir bug/foo
touch bug/foo/__init__.py
touch bug/foo/bar.py
python3 -m compileall -d "<prefix>" bug
python2 -m compileall -d "<prefix>" bug
echo "prefix embedded in PY3 pyc code object for lib.foo.bar:"
strings bug/foo/__pycache__/bar.cpython-3*.pyc | grep prefix
echo "prefix embedded in PY2 pyc code object for lib.foo.bar:"
strings bug/foo/bar.pyc | grep prefix Run that script and you'll see: Notice that the Python 3 pyc file contains a code.co_filename of "<prefix>/bar.py" instead of the correct value (that Python 2 inserts) of "<prefix>/foo/bar.py". |
This has probably been happening for many 3 releases. I noticed it on 3.6 when investigating a problem with wrong paths in tracebacks coming from code which we used compileall.compile_dir(src_root, quiet=1, ddir="<prefix">) on. I'm guessing ddir= (-d on the cli) isn't widely used? |
Ironically 3.9a4 gains some compileall enhancements that could be used as an awkward workaround from https://bugs.python.org/issue38112: python 2.7 compile_dir(d, ddir="<foo>") behavior can be had with I still intend to fix the actual ddir behavior as it is wrong. |
The regression was caused by the parallelization enhancement implementation from https://bugs.python.org/issue16104 |
meaning this regression was introduced in 3.5. |
belated postmortem: if there had been tests against the filename encoded in the pycs living in subdirs as generated by compile_dir, this regression would not have happened. |
keeping this open while i investigate if fixing 3.8 and 3.7 is feasible. if nothing else i'll try to add a note to the docs about the issue in 3.5-3.8 with a code sample suggested workaround. |
if anyone needs this on their older 3.6 or 3.5 trees, the 3.7/3.8 patch is a trivial backport. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: