*.py packaging, again

[Jacek Konieczny]

On Thu, Jul 14, 2011 at 07:31:28PM +0100, Artur Wroblewski wrote:
> 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.

But it never was the same. *.py files are executable code, *.pyc is only
optimized version of these. *.java cannot be run without compilation.

> 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).

This was not clear to me, otherwise I would have myself converted a few
packages until now.

> 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.

PyPy cannot replace CPython in every place, but can be useful for some
deployments to speed up some Python applications.

I think we should try to provide the PyPy itself and maybe a few basic
packages for it. E.g. Distribute, to have 'easy_install' working for
pypy. This way any other packages could be installed through
easy_install rather then from RPM – not the way 'supported in PLD', but
would make PyPy from PLD useful for those who need it. Having the 'pypy'
binary handy would be good enough from PLD.

To sum up:

- there is no easy way and no point to provide all our Python 2.7
  packages for CPython and PyPy. We can still build some as pypy-*
  and put in /usr/lib/pypy-*/site-packages

- we stop supporting python 3.{0,1}, and package *.py with __pycache__/*
  for Python 3.2

- for Python 2.7 things stay the old way (though, I would prefer to stop
  the strict no *.py policy, without forcing the other way either)

- maybe, some day, RPM will manage the files in some other, smart way,
  but that is another discussion.

Greets,
        Jacek