From holger at merlinux.eu  Wed Oct  1 12:10:33 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 1 Oct 2008 12:10:33 +0200
Subject: [py-dev] [py-svn] r58518 - py/build/fedora
In-Reply-To: <348899050810010303n3c175023x1592d92477c8e18b@mail.gmail.com>
References: <20081001093927.EFCA516A03F@codespeak.net>
	<348899050810010303n3c175023x1592d92477c8e18b@mail.gmail.com>
Message-ID: <20081001101033.GD6829@trillke.net>

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


From cfbolz at gmx.de  Wed Oct  1 12:21:57 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 1 Oct 2008 12:21:57 +0200
Subject: [py-dev] [py-svn] r58518 - py/build/fedora
In-Reply-To: <20081001101033.GD6829@trillke.net>
References: <20081001093927.EFCA516A03F@codespeak.net>
	<348899050810010303n3c175023x1592d92477c8e18b@mail.gmail.com>
	<20081001101033.GD6829@trillke.net>
Message-ID: <348899050810010321na751a8au7a3c5148d9424e0e@mail.gmail.com>

Hi Holger,

2008/10/1 holger krekel <holger at merlinux.eu>:
[snip]
> 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.

Ok, makes sense as a strategy. I guess in an environment where all
your software is packaged you can depend on the correct Python version
being there in theory, so I kind of understand where the Fedora people
are coming from.

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

Right, as they probably won't switch to 2.6 for a while.

Cheers,

Carl Friedrich


From jussi.rasinmaki at simosol.fi  Mon Oct  6 16:40:23 2008
From: jussi.rasinmaki at simosol.fi (=?ISO-8859-1?Q?Jussi_Rasinm=E4ki?=)
Date: Mon, 6 Oct 2008 17:40:23 +0300
Subject: [py-dev] doctest & looponfail
In-Reply-To: <f674190e0810060736k299d4a76y4ed4c744b86680aa@mail.gmail.com>
References: <f674190e0810060736k299d4a76y4ed4c744b86680aa@mail.gmail.com>
Message-ID: <f674190e0810060740v10c8248dne28b56812f5040b8@mail.gmail.com>

Hi,

Here's a doctest file I tried to run with py.test -f (I mentioned
three files on #pylib, but at closer look two of those were just empty
placeholders so far).

Jussi
----------------------------------------
Jussi Rasinm?ki
Simosol Oy
Etel?inen Asemakatu 2B, 11130 Riihim?ki, Finland
+358-400-382364
jussi.rasinmaki at simosol.fi
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_modelchain-py.txt
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20081006/db63b8ef/attachment.txt>

From holger at merlinux.eu  Fri Oct 10 15:04:47 2008
From: holger at merlinux.eu (holger krekel)
Date: Fri, 10 Oct 2008 15:04:47 +0200
Subject: [py-dev] [pypy-dev] sympy tests: pypy vs cpython
	incompatibilities
In-Reply-To: <85b5c3130810100412o2dec14d7rcd353f268c10d4f8@mail.gmail.com>
References: <85b5c3130810081719i4c337f9at9117a79419e62dfb@mail.gmail.com>
	<85b5c3130810100412o2dec14d7rcd353f268c10d4f8@mail.gmail.com>
Message-ID: <20081010130447.GN6829@trillke.net>

Hi Ondrej, 

On Fri, Oct 10, 2008 at 13:12 +0200, Ondrej Certik wrote:
> On Thu, Oct 9, 2008 at 2:19 AM, Ondrej Certik <ondrej at certik.cz> wrote:
> > Hi,
> >
> > if you want to get many bugreports, here's how. :)
> >
> > $ git clone git://git.sympy.org/sympy.git
> > $ cd sympy
> > $ python
> >>>> import sympy
> >>>> sympy.test("sympy/core")
> > [...]
> > ============ tests finished: 292 passed, 9 xfailed in 1.40 seconds =============
> > True
> >>>>
> >
> >
> > This works in python2.4, python2.5 (there are some failures in
> > python2.6) and it *doesn't* require py.test, just pure python.
> 
> Holger asked me why we are not using py.test anymore and any
> particular feedback. I am not subscribed to py-dev, so I just post it
> here.

thanks - i am cross-posting this to py-dev. 
 
> We still use py.test. But I also want to have something simple
> (current implementation has 335 lines) that we can include with sympy,
> because py.test is not so easy to install --- you need to install
> setuptools, which in particular require python to be compiled with
> zlib. So while py.test is fine let's say in Debian or Ubuntu, it was
> quite a pain for me to install it 6x on our buildbots:
> 
> http://buildbot.sympy.org/waterfall

> (E.g. I compiled python2.4, 2.5, 2.6 from python.org, then I realized
> that setuptools cannot be installed, because python didn't compile
> with the zlib module, because I didn't have the zlib-dev Debian
> package installed, so I fixed that, recompiled python, installed
> setuptools 6x and then installed py.test 6x).

Hum, that's kind of bothersome, i agree.  I wonder if going
away from setuptools makes sense, shouldn't be hard. 

> And we are also porting sympy to jython and it's just easier to just
> install sympy and do "sympy.test()" to test that all is ok.

right, makes sense. 
 
> We also thought we could just include py.test in sympy, but py.test
> depends on the py lib and it is big. So I just rewrote the necessary
> thing from scratch and it can do what I want.

Raymond Hettinger at some point also wrote a pytest one-file
script with a subset of features.  Probably providing 
something like that officially makes sense.   Also 
i'd like to work a bit on minimizing py lib (i plan
to factor some parts out into plugins soon) - most of it
is actually used from py.test. 

best,

holger

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 


From ondrej at certik.cz  Fri Oct 10 15:24:34 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Fri, 10 Oct 2008 15:24:34 +0200
Subject: [py-dev] [pypy-dev] sympy tests: pypy vs cpython
	incompatibilities
In-Reply-To: <20081010130447.GN6829@trillke.net>
References: <85b5c3130810081719i4c337f9at9117a79419e62dfb@mail.gmail.com>
	<85b5c3130810100412o2dec14d7rcd353f268c10d4f8@mail.gmail.com>
	<20081010130447.GN6829@trillke.net>
Message-ID: <85b5c3130810100624v59f9385eg282ea2864d624618@mail.gmail.com>

>> We also thought we could just include py.test in sympy, but py.test
>> depends on the py lib and it is big. So I just rewrote the necessary
>> thing from scratch and it can do what I want.
>
> Raymond Hettinger at some point also wrote a pytest one-file
> script with a subset of features.  Probably providing
> something like that officially makes sense.   Also
> i'd like to work a bit on minimizing py lib (i plan
> to factor some parts out into plugins soon) - most of it
> is actually used from py.test.


Thanks for the work on py.test. The user interface is still I think
the best from all the testing frameworks around. I think it's cool to
have something small & simple that projects can just copy verbatim,
and then full featured py.test, that one can use when it is installed.
In fact, that's how I use it.

Ondrej