Skip to content
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 -f doesn't force to write bytecode files #63731

Closed
Sworddragon mannequin opened this issue Nov 9, 2013 · 8 comments
Closed

compileall -f doesn't force to write bytecode files #63731

Sworddragon mannequin opened this issue Nov 9, 2013 · 8 comments
Labels
easy stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@Sworddragon
Copy link
Mannequin

Sworddragon mannequin commented Nov 9, 2013

BPO 19532
Nosy @ned-deily, @bitdancer, @vajrasky
Files
  • compileall_force.patch
  • compileall_force_v2.patch
  • compileall_force_v3.patch
  • 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:

    assignee = None
    closed_at = <Date 2013-12-16.01:58:23.429>
    created_at = <Date 2013-11-09.06:14:31.693>
    labels = ['easy', 'type-bug', 'library']
    title = "compileall -f doesn't force to write bytecode files"
    updated_at = <Date 2013-12-16.01:58:23.427>
    user = 'https://bugs.python.org/Sworddragon'

    bugs.python.org fields:

    activity = <Date 2013-12-16.01:58:23.427>
    actor = 'r.david.murray'
    assignee = 'none'
    closed = True
    closed_date = <Date 2013-12-16.01:58:23.429>
    closer = 'r.david.murray'
    components = ['Library (Lib)']
    creation = <Date 2013-11-09.06:14:31.693>
    creator = 'Sworddragon'
    dependencies = []
    files = ['32553', '32559', '32560']
    hgrepos = []
    issue_num = 19532
    keywords = ['patch', 'easy']
    message_count = 8.0
    messages = ['202463', '202466', '202479', '202490', '202517', '202518', '206273', '206274']
    nosy_count = 5.0
    nosy_names = ['ned.deily', 'r.david.murray', 'Sworddragon', 'python-dev', 'vajrasky']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue19532'
    versions = ['Python 3.3', 'Python 3.4']

    @Sworddragon
    Copy link
    Mannequin Author

    Sworddragon mannequin commented Nov 9, 2013

    The force-option from compileall seems not to rebuild the bytecode files if they already exist. Here is an example of 2 calls:

    root@ubuntu:# python3 -m compileall -f
    Skipping current directory
    Listing '/usr/lib/python3.3'...
    Compiling '/usr/lib/python3.3/phello.foo.py'...
    Compiling '/usr/lib/python3.3/_compat_pickle.py'...
    Compiling '/usr/lib/python3.3/_dummy_thread.py'...
    ...
    Compiling '/usr/lib/python3.3/webbrowser.py'...
    Compiling '/usr/lib/python3.3/xdrlib.py'...
    Compiling '/usr/lib/python3.3/zipfile.py'...
    Listing '/usr/lib/python3.3/plat-x86_64-linux-gnu'...
    Listing '/usr/lib/python3.3/lib-dynload'...
    Listing '/usr/local/lib/python3.3/dist-packages'...
    Listing '/usr/lib/python3/dist-packages'...
    root@ubuntu:
    # python3 -m compileall -f
    Skipping current directory
    Listing '/usr/lib/python3.3'...
    Listing '/usr/lib/python3.3/plat-x86_64-linux-gnu'...
    Listing '/usr/lib/python3.3/lib-dynload'...
    Listing '/usr/local/lib/python3.3/dist-packages'...
    Listing '/usr/lib/python3/dist-packages'...

    @Sworddragon Sworddragon mannequin added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Nov 9, 2013
    @ned-deily
    Copy link
    Member

    Looking at the compileall module, it appears that -f and options other than -b have never (or, at least, for a long time, not) been supported when directories or files are not supplied and it defaults to <directories from sys.path>. Note the call in main() to compile_path vs those to compile_file or compile_dir. I'm not sure if there was a good reason for the difference but it seems like a bug now. Would you care to work on a patch and/or tests?

    @ned-deily ned-deily added the easy label Nov 9, 2013
    @vajrasky
    Copy link
    Mannequin

    vajrasky mannequin commented Nov 9, 2013

    Attached the patch to fix the problem. I did not modify the unit test because the bug was located in the __main__ part of Lib/compileall.

    @bitdancer
    Copy link
    Member

    test_compileall has fairly extensive tests of the command line behavior, added when we refactored from optparse to argparse. So a test should be added for this case.

    @vajrasky
    Copy link
    Mannequin

    vajrasky mannequin commented Nov 10, 2013

    Ah, I missed that. I made this assumption because when I executed other modules manually, they were there just for testing functionality (such as shlex and aifc).

    Added test.

    @vajrasky
    Copy link
    Mannequin

    vajrasky mannequin commented Nov 10, 2013

    Tidied up the test.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Dec 16, 2013

    New changeset 6afad4f29249 by R David Murray in branch '3.3':
    bpo-19532: make compileall with no file/dir args respect -f and -q.
    http://hg.python.org/cpython/rev/6afad4f29249

    New changeset 0e07ab605e0b by R David Murray in branch 'default':
    Merge: bpo-19532: make compileall with no file/dir args respect -f and -q.
    http://hg.python.org/cpython/rev/0e07ab605e0b

    @bitdancer
    Copy link
    Member

    Thanks, Vajrasky.

    I did not backport this to 2.7 because the code is different and we don't have proper tests there, so the chance of breaking something is higher than the benefit of fixing it.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    easy stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants