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://codespeak.net/pipermail/py-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

From simon at arrowtheory.com  Tue Nov  4 02:27:55 2008
From: simon at arrowtheory.com (Simon Burton)
Date: Tue, 4 Nov 2008 12:27:55 +1100
Subject: [py-dev] py.test + cython
Message-ID: <20081104122755.8d140430.simon@arrowtheory.com>


I have problems with py.test (all untraceable thanks to py.test's builtin magic)
Looks like it is picking up pyx source files (is this from the module's __file__ ?) and choking.
Does anyone here use py.test ?

Simon.

From holger at merlinux.eu  Tue Nov  4 03:46:48 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 4 Nov 2008 03:46:48 +0100
Subject: [py-dev] py.test + cython
In-Reply-To: <20081104122755.8d140430.simon@arrowtheory.com>
References: <20081104122755.8d140430.simon@arrowtheory.com>
Message-ID: <20081104024648.GE15982@trillke.net>

Hi Simon,

On Tue, Nov 04, 2008 at 12:27 +1100, Simon Burton wrote:
> I have problems with py.test (all untraceable thanks to py.test's builtin magic)
> Looks like it is picking up pyx source files (is this from the module's __file__ ?) and choking.
> Does anyone here use py.test ?

sure - this is a development mailing list for py.test and the py lib. 
normally, py.test wouldn't pick up files with a .pyx extension. 
could you be a bit more specific about what you are doing? 
which version of pyp.test you are using, how output looks like
(even if you think it's not providing enough info or shows "magicness")? 

holger

From simon at arrowtheory.com  Wed Nov  5 23:31:12 2008
From: simon at arrowtheory.com (Simon Burton)
Date: Thu, 6 Nov 2008 09:31:12 +1100
Subject: [py-dev] py.test + cython
In-Reply-To: <20081104024648.GE15982@trillke.net>
References: <20081104122755.8d140430.simon@arrowtheory.com>
	<20081104024648.GE15982@trillke.net>
Message-ID: <20081106093112.19f98392.simon@arrowtheory.com>


$ svn info ~/local/pypy/py/
Path: /home/simon/local/pypy/py
URL: http://codespeak.net/svn/py/dist/py
Repository Root: http://codespeak.net/svn
Repository UUID: fd0d7bf2-dfb6-0310-8d31-b7ecfe96aada
Revision: 59741
Node Kind: directory
Schedule: normal
Last Changed Author: hpk
Last Changed Rev: 58517
Last Changed Date: 2008-10-01 19:24:24 +1000 (Wed, 01 Oct 2008)

traceback:

    def runtraced(self, colitem):
        if self.shouldclose(): 
            raise Exit, "received external close signal" 
    
        outcome = None 
        colitem.startcapture() 
        try: 
            self.start(colitem)
            try: 
                try:
                    if colitem._stickyfailure: 
                        raise colitem._stickyfailure 
>                   outcome = self.run(colitem) 

/home/simon/local/pypy/py/test/session.py:84:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def run(self, colitem): 
        if self.config.option.collectonly and isinstance(colitem, py.test.collect.Item): 
            return 
        if isinstance(colitem, py.test.collect.Item): 
            colitem._skipbykeyword(self.config.option.keyword)
>       res = colitem.run() 

/home/simon/local/pypy/py/test/session.py:107:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def run(self): 
>       self._prepare()

/home/simon/local/pypy/py/test/collect.py:336:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def _prepare(self): 
        if not hasattr(self, '_name2items'): 
            ex = getattr(self, '_name2items_exception', None)
            if ex is not None: 
                raise ex[0], ex[1], ex[2]
            try: 
>               self._name2items = self._buildname2items()

/home/simon/local/pypy/py/test/collect.py:328:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def _buildname2items(self): 
        # NB. we avoid random getattrs and peek in the __dict__ instead
        d = {}
>       dicts = [getattr(self.obj, '__dict__', {})]

/home/simon/local/pypy/py/test/collect.py:298:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def fget(self):
        try: 
            return self._obj   
        except AttributeError: 
>           self._obj = obj = self._getobj() 

/home/simon/local/pypy/py/test/collect.py:105:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def _getobj(self): 
E       return self.parent.obj()  
>       TypeError: __init__() takes exactly 2 arguments (1 given)

/home/simon/local/pypy/py/test/collect.py:436: TypeError
____________________________________________________________________

On Tue, 4 Nov 2008 03:46:48 +0100
holger krekel <holger at merlinux.eu> wrote:

> Hi Simon,
> 
> On Tue, Nov 04, 2008 at 12:27 +1100, Simon Burton wrote:
> > I have problems with py.test (all untraceable thanks to py.test's builtin magic)
> > Looks like it is picking up pyx source files (is this from the module's __file__ ?) and choking.
> > Does anyone here use py.test ?
> 
> sure - this is a development mailing list for py.test and the py lib. 
> normally, py.test wouldn't pick up files with a .pyx extension. 
> could you be a bit more specific about what you are doing? 
> which version of pyp.test you are using, how output looks like
> (even if you think it's not providing enough info or shows "magicness")? 
> 
> holger

From simon at arrowtheory.com  Thu Nov  6 01:38:23 2008
From: simon at arrowtheory.com (Simon Burton)
Date: Thu, 6 Nov 2008 11:38:23 +1100
Subject: [py-dev] py.test + cython
In-Reply-To: <20081106093112.19f98392.simon@arrowtheory.com>
References: <20081104122755.8d140430.simon@arrowtheory.com>
	<20081104024648.GE15982@trillke.net>
	<20081106093112.19f98392.simon@arrowtheory.com>
Message-ID: <20081106113823.93ad5707.simon@arrowtheory.com>

On Thu, 6 Nov 2008 09:31:12 +1100
Simon Burton <simon at arrowtheory.com> wrote:

...
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
>     def _getobj(self): 
> E       return self.parent.obj()  
> >       TypeError: __init__() takes exactly 2 arguments (1 given)
> 
> /home/simon/local/pypy/py/test/collect.py:436: TypeError


Aha! Looks like py.test is picking up a class that happened to have prefix Test.
It is not a unit test class (has no test_* methods); i just made sure it could be
constructed with one argument.

Simon.



From elin at splunk.com  Sat Nov  8 02:13:56 2008
From: elin at splunk.com (Elizabeth Lin)
Date: Fri, 7 Nov 2008 17:13:56 -0800
Subject: [py-dev] Py.test for 64bit windows?
Message-ID: <C53A27D4.1112%elin@splunk.com>

Hi,

I was just wondering if there are  any plans to support windows 64bit for py.test?

Thanks,
Liz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20081107/6969e53f/attachment.htm 

From holger at merlinux.eu  Sat Nov  8 09:22:17 2008
From: holger at merlinux.eu (holger krekel)
Date: Sat, 8 Nov 2008 09:22:17 +0100
Subject: [py-dev] Py.test for 64bit windows?
In-Reply-To: <C53A27D4.1112%elin@splunk.com>
References: <C53A27D4.1112%elin@splunk.com>
Message-ID: <20081108082217.GL15982@trillke.net>

Hi Elizabeth, 

On Fri, Nov 07, 2008 at 17:13 -0800, Elizabeth Lin wrote:
> Hi,
> 
> I was just wondering if there are  any plans to support windows 64bit for py.test?

Do you refer to the py lib downloads not having
binary eggs for windows 64? 

hum. the only reason these are binary eggs is that the
py lib includes the "greenlet" C extension module. 
I don't have access to a win32 machine so i can't
try building it.  

however, py.test does not depend on greenlets 
so installing from the source package (zip file) 
should work.  i thought one could say "python setup.py
install_lib" but i am not sure - commenting out the 
greenlet C-extension in the setup.py file and
"python setup.py install" works definitely. 

if that doesn't work well for you please get back - 
i'll see if i can quickly install a py-0.9.2 install up 
without greenlets. 

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 denis.bilenko at gmail.com  Mon Dec  8 20:14:16 2008
From: denis.bilenko at gmail.com (Denis Bilenko)
Date: Tue, 9 Dec 2008 01:14:16 +0600
Subject: [py-dev] greenlet on ARM/unix
Message-ID: <95d6e98c0812081114s5152e2adi11fb21ce433f3a5@mail.gmail.com>

Hi,

First, thanks to the developers for a very nice library. It's a real
pleasure to use.

How much effort would it require to port py.magic.greenlet to ARM architecture?
Maybe someone has thought about it and can provide some guidance.
I'd like to do the porting myself but I have no idea how one should go about it,
so any help is appreciated.

Thanks,
Denis.

From phil at freehackers.org  Fri Dec 12 18:20:50 2008
From: phil at freehackers.org (Philippe Fremy)
Date: Fri, 12 Dec 2008 18:20:50 +0100
Subject: [py-dev] Avoiding directories when running py.test
Message-ID: <49429D72.1040208@freehackers.org>


Hi,

I have a project where I am using py.test, that contains a copy of an
external project.

That external project has some test directories and files, which are not
using py.test

Is there a way I can tell py.test to avoid those directories ?

	cheers,

	Philippe


From Jim.Vickroy at noaa.gov  Fri Dec 12 20:21:23 2008
From: Jim.Vickroy at noaa.gov (Jim Vickroy)
Date: Fri, 12 Dec 2008 12:21:23 -0700
Subject: [py-dev] Avoiding directories when running py.test
In-Reply-To: <49429D72.1040208@freehackers.org>
References: <49429D72.1040208@freehackers.org>
Message-ID: <4942B9B3.7080005@noaa.gov>

Philippe Fremy wrote:
> Hi,
>
> I have a project where I am using py.test, that contains a copy of an
> external project.
>
> That external project has some test directories and files, which are not
> using py.test
>
> Is there a way I can tell py.test to avoid those directories ?
>   
Does the information in sections 2.3 
<http://codespeak.net/py/dist/test.html#automatic-collection-of-tests-on-all-levels> 
and 2.5 
<http://codespeak.net/py/dist/test.html#selecting-tests-by-keyword> of 
the manual help?
> 	cheers,
>
> 	Philippe
>
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20081212/2bad74a9/attachment.htm 

From fijall at gmail.com  Fri Dec 12 21:18:46 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 12 Dec 2008 21:18:46 +0100
Subject: [py-dev] Avoiding directories when running py.test
In-Reply-To: <49429D72.1040208@freehackers.org>
References: <49429D72.1040208@freehackers.org>
Message-ID: <693bc9ab0812121218y41177052ja1e38c17906d81ee@mail.gmail.com>

Put into this directory file named conftest.py which contains this:

import py

class Directory(py.test.collect.Directory):

    def run(self):
        return []

On Fri, Dec 12, 2008 at 6:20 PM, Philippe Fremy <phil at freehackers.org> wrote:
>
> Hi,
>
> I have a project where I am using py.test, that contains a copy of an
> external project.
>
> That external project has some test directories and files, which are not
> using py.test
>
> Is there a way I can tell py.test to avoid those directories ?
>
>        cheers,
>
>        Philippe
>
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
>