fedora-python / compileall2

Enhanced Python `compileall` module

fedora-python

Sphinx project for the decomissioned https://fedora-python.readthedocs.io/

For current information about the Fedora Python SIG, please visit our wiki:

https://fedoraproject.org/wiki/SIGs/Python

compileall2's Issues

PyPI 0.7.1 sdist doesnt include LICENSE

--exclude option with regex path

brp-python-bytecompile has exclude option with path regex:

https://github.com/rpm-software-management/rpm/blob/master/scripts/brp-python-bytecompile

It uses this regex not to compile stuff in some dirs:

"/bin/|/sbin/|/usr/lib(64)?/python[0-9]\.[0-9]|/usr/share/doc"

In order to be able to use compileall2 in brp-python-bytecompile, it needs to gain support for exclude option. It can either support regular expressions or repeated file globs.

I suppose for us it will be more convenient to check the excluded paths after the -s and -a options are applied.

Try to use compileall2 in Fedora

I'll try to hack on python-rpm-macros and brp-python-bytecompile to use compileall2.

Let's see how far I get.

Python 3.4 doesn't produce optimzied bytecode

$ mkdir empty
$ echo '0' > empty/zero.py
$ python3.4 -m compileall2 -o 0 -o 1 -o 2 empty/
Listing 'empty/'...
Compiling 'empty/zero.py'...
$ ls empty/__pycache__/
zero.cpython-34.pyc
$ rm empty/__pycache__/ -rf
$ python3.5 -m compileall2 -o 0 -o 1 -o 2 empty/
Listing 'empty/'...
Compiling 'empty/zero.py'...
$ ls empty/__pycache__/
zero.cpython-35.opt-1.pyc  zero.cpython-35.opt-2.pyc  zero.cpython-35.pyc

Note that 3.4 was the last version with .pyo files and the results should include __pycache__/zero.cpython-34.pyo.

Should append be prepend?

"append" option makes me think the path goes at the end. Here it puts the path in front. Should it be called "prepend"?

Add a note about license into module header

to be sure that the module will include some info about licensing even when it's distributed without other files.

RFE: Add CLI argument for pyc invalidation mode

It would be nice if compileall2 supported a CLI argument for setting the desired pyc invalidation mode.

RFE: Option to hardlink duplicate bytecache files of different opt. levels

I'd like to have and option of compileall that deduplicates identical .pyc files of the same module if compiled for different optimization levels.

Example:

$ python -m compileall -o0 -o1 -o2 --hardlink-dupes ...

This would hardlink module.cpython-3?.pyc with module.cpython-3?.opt-1.pyc with module.cpython-3?.opt-1.pyc if identical, on operating systems supporting hardlinks.

Given the nature of the bytecode caches, the non-optimized, optimized level 1 and optimized level 2 .pyc files may or may not be identical.

Consider the following Python module:

1

All three bytecode cache files would by identical.

While with:

assert 1

Only the two optimized cache files would be identical with each other.

And this:

"""Dummy module docstring"""
1

Would produce two identical bytecode cache files but the opt-2 file would differ.

Only modules like this would produce 3 different files:

"""Dummy module docstring"""
assert 1

Hardlinking identical .pyc files can cause significant storage savings. As a single data point: On my workstation I have 360 MiB of various Python 3.7 bytecode files in /usr and I can save 108 MiB.

Travis CI fails with: Couldn't use data file '/src/.coverage': Looks like a coverage 4.x data file.

The Travis CI job fails in both #14 and #15 wiht:

Couldn't use data file '/src/.coverage': Looks like a coverage 4.x data file. Are you mixing versions of coverage?
ERROR: InvocationError for command '/src/.tox/py3?/bin/coverage run --append -m py.test' (exited with code 1)

Backport fixes for compile_dir ddir= and CLI -d behavior

See https://bugs.python.org/issue39769 and the fixes within, those should be applied to this fork.

If the .pyc file can't be written, compileall2 fails silently

During testing upstream, it was found that py_compile, and thus compileall, silently skips writing .pyc files it can't write (because of path size limits; probably also because of permissions etc.).

For Fedora, it would make sense to fail with an exception (or error exit code). It should probably be an option – not everyone will want it.