*.py packaging, again

Jakub Bogusz qboosh at pld-linux.org
Thu Jul 14 19:27:01 CEST 2011


On Thu, Jul 14, 2011 at 06:34:11PM +0200, Jacek Konieczny wrote:
> On Thu, Jul 14, 2011 at 05:44:19PM +0200, Jakub Bogusz wrote:
> > > We gain:
> > > - ability to use the installed noarch packages by other Python 2.7
> > >   implementations (like PyPy)
> > 
> > Are particular PyPy versions meant to be compatible with particular
> > Python 2 major version?
> 
> PyPy 1.5 is compatible with Python 2.7. As far as pure-python (noarch in
> PLD) *.py modules are concerned.
> 
> BTW PyPy also generates *.pyc files, in a quite different format that
> those from Python 2.7 and they are most probably architecture dependant.
> 
> This gives some ugly behaviour:

Very ugly... so PyPy can't refer to the system directory containing
(pure-)python 2.7 modules.
At most sources (*.py) could be symlinked to pypy-specific directory.

> > But there are still many packages not using setuptools(?) 
> 
> setuptools are dead and ever supported Python 3 AFAIK
> There are distutils (part of the man Python library), distribute (fork
> of setuptools, supporting Python 3 and 2to3 conversion) and on the way
> are 'packaging' and distutils2...

OK, I've seen some names, but didn't know which should be currently
used.

> Anyway, that doesn't change a thing in 'packaging python 2 way' or
> 'packaging python 3 way'
> 
> > and thus
> > packaged in Python 2 way.
> 
> Most of our python3-* packages were never updated or rebuilt for the
> python3 changes. I think they won't even build, as the *.pyc files
> listed in %files are missing.
> 
> > Should we enforce the new packaging method for them?
> > %py3_comp/%py3_ocomp macros use the old one.
> 
> Those only start the standard python compilation functions. For Python <
> 3.2 they will produce X.py[co] for every X.py and for Python >= 3.2 they
> will produce __pycache__/X.magic.py[co] for every X.py

Right. I was misleaded by some python3-* packages (namely pycairo and
pygobject) still producing *.py[co] in the same directory as *.py.

> What is will not work in this case are not the macros, but the %files
> section. And it is hard to write a spec so both python 3.1 and 3.2 are
> supported.

IMO we could assume that "python3" means ">= 3.2" and don't maintain
support for 3.0/3.1.

> Additionally if %py3_postclean is run (*.py removed) then, even if
> %files are 'correct', the package won't work (*.pyc from __pycache__
> won't be ever loaded)

Right.


-- 
Jakub Bogusz    http://qboosh.pl/


More information about the pld-devel-en mailing list