*.py packaging, again

[Artur Wroblewski]

On Thu, Jul 14, 2011 at 8:44 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
[...]
> We lose:
> - a little bit of the disk space
> - some 'purity' some people see in not distributing 'sources'

IMHO, it was not about purity but quite practical aspect of
file distribution (src vs. bin) - we treated byte compiled files
for Java and Python the same way, no src allowed.

Now, Python's idea about byte compiled files evolved into different
concept - cache files? Another game changer is pypy, of course.

Few months ago we agreed on *.py distribution for Python 3.2 (IMHO,
that implies we do not longer support 3.0 and 3.1 in python-*.spec). Lack
of 3.2 in Th is matter of time and resources to recompile the packages,
not __pycache__ problem.

We should treat cpython and pypy as we would treat two compilers,
which optimize code in different way. We will not build code with gcc
and Intel compilers and put two versions of packages on ftp.

IMHO, at the moment, we should settle on one Python "compiler". Obvious
choice is cpython, now. You want pypy - use its mechanism (hopefully it
exists) to put compiled bytecode in temp directory (or whatever).

[...]

Best regards,

Artur