python3.2+ compiled files

[Elan Ruusamäe]

On 02/04/11 21:11, Jakub Bogusz wrote:
> It seems that since python 3.2 upstream changed the default way
> of creating compiled files: instead of *.pyc/*.pyo in the same
> directory that .py file exists, the compiled files are created
> in __pycache__ subdirectory.
> According to some googled information, the "old method" (files created
> in the same directory by compileall) still works in the same way.
> In case of the "new method", compiled files are searched in __pycache__
> subdirectory only if source file exists.
>
> I'm not sure if the new method affects only (c)python 3.2 installation,
> or all modules installed using distutils or so.
>
> So we have to decide how to package python distribution (and possibly
> all python3 modules, if distutils use __pycache__ too) - there are
> two solutions:
>
> - package all modules in source form together with __pycache__
>    subdirectories
>
> - stick to "old way" - manually py_comp/py_ocomp all python files,
>    package *.py[co] without using __pycache__ subdirectories
>

i always liked the pld way of packaing only .pyc/.pyo for runtime

so my vote goes for keeping the old .py[co] method, and perhaps change 
to make is package only .pyc, it is rather ratre somebody invokes python 
with -O option so the .pyo is to be needed. or why it was packaged in 
first place? to get files owned in case somebody invokes as root and 
.pyo gets created? perhaps package .pyc as regular files and .pyo as 
ghosted then.

also, python supports bundling the libraries as .zip files too, what 
about that approach :)

$ strace -ff -efile python -c "import os" 2>&1|grep .zip
stat64("/usr/lib/python27.zip", 0xbff4e97c) = -1 ENOENT (No such file or 
directory)
stat64("/usr/lib/python27.zip", 0xbff4e97c) = -1 ENOENT (No such file or 
directory)

as for the .py sources packaging, i'd move them to -debuginfo package so 
the could be installed optionally

-- 
glen