Created attachment 99328 [details]
Add python_sitelib and python_sitearch to macros

This was further discussed on fedora-devel and I have also suggested
the following (or their ilk)

%pythonprefix /usr
%__python %{pythonprefix}/bin/python
%pythonversion %(python -c 'import sys;print(sys.version[0:3])')
%pythonpath %{pythonprefix}/lib/python%{pythonversion}
%pythoninclude %{pythonprefix}/include/python%{pythonversion}
                                                                     
                                
Harald Hoyer contributed with multilib support:

%pythondir %(python -c 'from distutils import sysconfig; print
sysconfig.get_python_lib(0,0,prefix=%{pythonprefix})')
                                                                     
                                 %pyexecdir %(python -c 'from
distutils import sysconfig; print
sysconfig.get_python_lib(1,0,prefix=%{pythonprefix})')
                                                                     
                                

Can we PLEASE get some closure on this ...

Hi, can we please get this (or something at least reminiscent of it)
into FC4.

It's been discussed on the fedora-dev list a couple of times now, and
publishing something will give us Extras packagers something
definitive to rely upon for the future.

Current rpm CVS has pythondeps.sh, which implements provides/requires
python(abi) = $PYVER.

But it does it in a weird, IMO somewhat ugly way, some of which is
probably to support ancient Python versions.  But there are ways to
improve it; for example now it hardcodes "python", ie. is off sync
with %{__python}, and is also internally inconsistent ("python" vs
"/usr/bin/python*").

Because that's already in, fixing it is higher priority than adding
new things.  And quite frankly, with the possible exception of the
python include dirs, I don't see much value in all the stuff in
comment 2.  Wouldn't the two macros (+ possibly includedir) in my
initial submission be enough?

*** Bug 128981 has been marked as a duplicate of this bug. ***

Ville's two macros are far from being enough! As stated in Bug 128981
(which has now been marked as a duplicate without being one), these
features are also needed in real, practical Python packaging

python_version: version of current python interpreter
pycomp:  Generate normal (.pyc) byte-compiled files.
pycompo  Generate optimized (.pyo) byte-compiled files.

Please refer to Bug 128981 for an implementation of this.

The implemenation of %pythonversion in comment 2 is incomplete an will
fail eventually. A correct implementation would be:

%pythonversion %(__python -c 'import sys; from string import split,
join; print join(split(split(sys.version)[0], ".")[:2], ".")')

THis will work even if a version component would have two digits.

rpm CVS already contains brp-python-bytecompile, which will generate
*.pyc and *.pyo.

And comment 4 mentions the ABI provision, which is already in CVS too,
although currently implemented inconsistently from other python stuff
in the macros.

With these already in place, I don't see why the two site-packages
macros plus possibly the include dir are "far from being enough". 
IMO, they're exactly enough.  If/after they're in, what do you need
the Python version for so often that it should be part of rpm?

Python peculier build macros added to rpm CVS. Should be in rpm-4.4.3-0.32 when built.

Hm, may I ask where did those macros originate from?  They appear to be  
semi-hardcoding many things that could (and should) be just queried from 
python itself.  
  
In particular, %py_libdir (defined as %{py_prefix}/lib/python%{py_ver}) is  
multilib challenged.  Like Perl, Python has a distinction between  
arch-specific and noarch dirs, the former of which  
is /usr/lib64/pythonX.Y/... and latter /usr/lib/pythonX.Y/... on x86_64.  See 
patch in comment 1 for a better implementation. 
 
What versions of Python are these macros expected to work with? 

The macros are probably from PLD about a year ago. PLD is what I usually refer toi first anyways.

Multilib easy fix is to do s/lib/%{_lib}/, but perhaps there is better yet.

No matter what, python (and perl and ruby and php ...) build macros
are headed out of rpm-build into other packages. I'm tired of attempting
consensus with a mass of competitive vendors and language bigots. So I'm
gonna push the macros out of rpm-build entirely, so that the vendors and bigots
can have it their own way.

The root problem with py_libdir is that there is only one such macro defined, 
and we'd actually need two.  As it is now, it's good(ish, apart from not 
querying it from python) for noarch python packages (only) on multilib archs.  
After a s/lib/%{_lib}/, it would be good for non-noarch packages (only) on 
multilib archs.  Can't have both. 
 
Splitting these macros out of rpm-build proper sounds like a sane thing to do. 

Fixed (again) in rpm CVS and rpm-4.4.3-0.47.