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