packaging pyc files - again

[Ville Skyttä]

On Mon, 2004-08-09 at 15:34, Jeff Pitman wrote:

> On Mon, 29 Mar 1999, Fred L. Drake wrote:
> >  Only use site-python/ if you really are confident that your package
> >will stand the test of Python interpreter updates.  Unless there is a
> >major problem with diskspace, just don't do this!

Python stuff is usually installed into site-packages, which is under the
versioned pythonX.X dir, so this is hardly a problem for usual python
extension packages.

> Couple of questions I have on the template:

Ok, I have been working on the template, so here's my .02€'s.  I'm not a
Master of Python though, feel free to correct any misunderstandings.

> 1. Why do you install with -O1 when you're not going to include the .pyo 
> and just %ghost them?

If *.pyo are not installed, %ghost'ing them is a good idea in order to
get rid of them on package erase as they may be silently created after
package installation eg. by running a "#!/usr/bin/python -O" script
which imports those files.

Installing with -O1 is just a clean way of getting the files created
instead of having to manually loop through all installed *.py and
touch'ing or whatever the corresponding *.pyo so that they _can_ be
%ghost'd.  On the other hand, for python module packages that install
files into many dirs, if one wants to avoid rpm's warnings of files
being included twice, such looping + %ghost'ing + creating lists of
installed files is often convenient in %install anyway.

But with the simpler packages (probably a majority of them), everything
including %ghost'ing can be easily in %files, no need for such looping;
hence the -O1 trick is in the template by default.

> 2. Does worrying about .pyo also go under Fred's "Unless there is a 
> major problem with diskspace" axiom?

Actually including *.pyo adds almost no gain for most library packages. 
It does increase the package sizes though.  It is a different case when
the package includes a "#!/usr/bin/python -O" script; then we know that
*.pyo will be created _and used_ (eg. rpmlint).

Installing *.pyc but not *.pyo is also IIRC the default behaviour what
happens when one follows the "usual upstream" instructions (./setup.py
build ; ./setup.py install).  I guess there's a reason for that.

> 3. Why worry about noarch packages vs arch-dependent when changes in the 
> Python API could break a package anyway?

I guess this is covered by the versioned site-packages dir.  I'm not
sure I understand though.  Are *.pyo arch-dependent?

> 4. If there are noarch packages, wouldn't it be prudent to execute the 
> compileall during %post since the Python marshalled code objects is 
> subject to change between different versions?

Dunno.  In general, the less %post and friends scriptlets the better,
and invoking compileall sounds a bit heavy to me.  With regards to
Fred's comment at the beginning of this message: for packages that
install *.py* files outside of the versioned python site-packages dir,
one could imagine that a "%triggerin -- python" with compileall could be
a good idea (or not to ship any *.pyc, *.pyo at all).