packaging pyc files - again

[Jeff Pitman]

On Monday 09 August 2004 23:03, Ville Skyttä wrote:
> 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.

*sigh*  I confused myself with what was meant by python_sitelib vs. 
python_sitearch.  For some reason site-python came into my head as to 
what was attempted here.  Now that I've dug a little deeper, I still 
don't know what the difference between sitelib and sitearch is on the 
posix platform.  get_python_lib() is going to 
return /usr/lib/pythonX.Y/site-packages and so is get_python_lib(1).  
The difference is whether to use sys.exec_prefix versus sys.prefix.  
And, if you print these out, currently, they are the same values: 
"/usr".

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

No problem.  I am not a master either.  Just providing my 2 ntd for 
discussion.

> [...]
> > 2. Does worrying about .pyo also go under Fred's "Unless there is a
> > major problem with diskspace" axiom?
> [...]
> 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.

You just said it: no gain! ;)  -O removes asserts() and -OO removes 
__doc__, which could potential break packages.  So, I think the -O 
concept was just an ephemeral implementation opening the door to "real" 
optimizations down the road, if they were ever worked on.

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

Sorry to mislead the entire discussion.  Leading back to the site-python 
confusion.  .pyc and .pyo are Architecture-*in*dependent files.  If you 
wanted, you could have a pure python module directory shared via samba 
and mac/nt/posix could all access it: using the same version of Python, 
of course.  

I took noarch to mean version-independent--don't ask me why.

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

So, for Python applications--as opposed to libraries--that install the 
bulk of their program bodies in /usr/share/%{name}, is there a standard 
procedure for this?  Or is a "Requires: python-abi = 2.3.3" good? Or...  

thanks,
-- 
-jeff