Mailman 3 October 2008 - pytest-dev

Re: [py-dev] [pypy-dev] sympy tests: pypy vs cpython incompatibilities
by holger krekel Oct. 10, 2008

Oct. 10, 2008

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(a)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

2 1

[py-dev] doctest & looponfail
by Jussi Rasinmäki Oct. 6, 2008

Oct. 6, 2008

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(a)simosol.fi

1 0

Re: [py-dev] [py-svn] r58518 - py/build/fedora
by holger krekel Oct. 1, 2008

Oct. 1, 2008

Hi Carl Friedrich, On Wed, Oct 01, 2008 at 12:03 +0200, Carl Friedrich Bolz wrote: > Hi Holger, > > 2008/10/1 <hpk(a)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

2 1