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
