[py-dev] [py-svn] r58518 - py/build/fedora

[holger krekel]

Hi Carl Friedrich, 

On Wed, Oct 01, 2008 at 12:03 +0200, Carl Friedrich Bolz wrote:
> Hi Holger,
> 
> 2008/10/1  <hpk at codespeak.net>:
> > Author: hpk
> > Date: Wed Oct  1 11:39:27 2008
> > New Revision: 58518
> [snip]
> > +fedora usually has >=python 2.4 anyway so one can
> > +erase py/compat/*.py (except __init__.py)
> > +and put the following into a new file, e.g. py/compat/fedora.py
> > +
> > +    import doctest
> > +    import optparse
> > +    import textwrap
> > +    import subprocess
> > +
> > +and then change py/__init__.py to have py.compat like this:
> > +
> > +'compat.doctest'         : ('./compat/fedora.py', 'doctest'),
> > +'compat.optparse'        : ('./compat/fedora.py', 'optparse'),
> > +'compat.textwrap'        : ('./compat/fedora.py', 'textwrap'),
> > +'compat.subprocess'      : ('./compat/fedora.py', 'subprocess'),
> 
> Wasn't the idea originally to not depend on the underlying stdlib for
> compat ever? Because then the py-lib user can rely on having always
> exactly the same version of these modules. I remember, because at one
> time I proposed to put a "try: import doctest except ImportError" into
> compat to get newer versions of these files if they are there.

yes, you are right.  However, currently it prevents things
from getting packaged on fedora because they have a policy of
not having duplication of stdlib python modules and are using
python>=2.4 on their distribution anyway.  This hasn't been a 
problem with other distributions i think.  thm (who does the
fedora packaging) will try to convince them to allow py/compat 
and otherwise the above will be a fedora and 0.9.2 specific change.  
In this case, i think it's pragmatic to not argue much. 

For 1.0 we should look into getting things from 2.6 and
maybe we then have a stronger case for the fedora packaging
reviewers.  

holger