From shiyee at shiyee.dk  Sat Jan  5 21:41:04 2008
From: shiyee at shiyee.dk (Mads Chr. Olesen)
Date: Sat, 05 Jan 2008 21:41:04 +0100
Subject: [py-dev] Simple patch to add port argument to SshGateway
Message-ID: <1199565664.6984.3.camel@localhost.localdomain>

Hi there!

Attached is a very simple patch, to allow specifying the port argument
when connecting via a SshGateway.

-- 
Mads Chr. Olesen <shiyee at shiyee.dk>
shiyee.dk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pyexecnet-sshport.patch
Type: text/x-patch
Size: 1077 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20080105/d20ec14a/attachment.bin 

From lac at openend.se  Sun Jan  6 11:36:02 2008
From: lac at openend.se (Laura Creighton)
Date: Sun, 06 Jan 2008 11:36:02 +0100
Subject: [py-dev] [TIP] Friendly py.test intro
In-Reply-To: Message from Titus Brown <titus@caltech.edu> 
	of "Sun, 06 Jan 2008 00:37:30 PST." <20080106083730.GA1416@caltech.edu> 
References: <20080106083730.GA1416@caltech.edu> 
Message-ID: <200801061036.m06Aa2hg018202@theraft.openend.se>

In a message of Sun, 06 Jan 2008 00:37:30 PST, Titus Brown writes:
>Hi all,
>
>here's a product of GHOP written by novanasa:
>
>	http://teckla.idyll.org/~t/transfer/py.test.html
>
>It's a simple introduction to py.test.
>
>I think with a bit of cleanup it could be quite useful.  Comments are
>welcome (here or directly on the issue, at
>
>   http://code.google.com/p/google-highly-open-participation-psf/issues/d
>etail?id=269
>
>)
>
>Does anyone have any ideas on where to host it?

Codespeak seems logical.  I've forwarded this to the py-dev mailing list,
where people ought to have opinions on where this should go.

Laura

>
>cheers,
>--titus
>
>_______________________________________________
>testing-in-python mailing list
>testing-in-python at lists.idyll.org
>http://lists.idyll.org/listinfo/testing-in-python

From sol at sr-research.com  Thu Jan 10 22:53:43 2008
From: sol at sr-research.com (Sol Simpson)
Date: Thu, 10 Jan 2008 16:53:43 -0500
Subject: [py-dev] issues running py.execnet
Message-ID: <000301c853d3$48dac1c0$04010164@LIAH>

I'm trying to test out py.execnet running one of the examples:

 

import py

gw = py.execnet.PopenGateway()

channel = gw.remote_exec("""

            import os

            channel.send(os.getpid())

            """)

remote_pid = channel.receive()

print remote_pid != py.std.os.getpid()

 

The issue is that the program hangs on the channel.receive() call. In task
manager I can see that a second python.exe has been launched, but that is
it. The only way to exit the app is to kill one of the python.exe in the
task manager.

 

Any insight would be very helpful.

 

I'm running python 2.5.1 on Windows XP SP2.

 

Thank you,

 

Sol

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20080110/65d6e553/attachment.htm 

From holger at merlinux.de  Fri Jan 11 17:59:34 2008
From: holger at merlinux.de (holger krekel)
Date: Fri, 11 Jan 2008 17:59:34 +0100
Subject: [py-dev] issues running py.execnet
In-Reply-To: <000301c853d3$48dac1c0$04010164@LIAH>
References: <000301c853d3$48dac1c0$04010164@LIAH>
Message-ID: <20080111165934.GV13357@solar.trillke>

Hi Sol, 

i tried the example with the 0.9.0 py release on my Windows XP box
with Python 2.5.1 - works for me. 

are you also using 0.9.0? 

Could you give me the output of
    
    >>> gw

and

    >>> gw.remote_exec("channel.send(42)").receive()

?

best, 

holger

On Thu, Jan 10, 2008 at 16:53 -0500, Sol Simpson wrote:
> I'm trying to test out py.execnet running one of the examples:
> 
>  
> 
> import py
> 
> gw = py.execnet.PopenGateway()
> 
> channel = gw.remote_exec("""
> 
>             import os
> 
>             channel.send(os.getpid())
> 
>             """)
> 
> remote_pid = channel.receive()
> 
> print remote_pid != py.std.os.getpid()
> 
>  
> 
> The issue is that the program hangs on the channel.receive() call. In task
> manager I can see that a second python.exe has been launched, but that is
> it. The only way to exit the app is to kill one of the python.exe in the
> task manager.
> 
>  
> 
> Any insight would be very helpful.
> 
>  
> 
> I'm running python 2.5.1 on Windows XP SP2.
> 
>  
> 
> Thank you,
> 
>  
> 
> Sol
> 
>  
> 

> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev


-- 
merlinux GmbH       
http://merlinux.de  

From holger at merlinux.de  Fri Jan 11 22:09:54 2008
From: holger at merlinux.de (holger krekel)
Date: Fri, 11 Jan 2008 22:09:54 +0100
Subject: [py-dev] issues running py.execnet
In-Reply-To: <001901c85486$04e7a560$04010164@LIAH>
References: <000301c853d3$48dac1c0$04010164@LIAH>
	<20080111165934.GV13357@solar.trillke>
	<001901c85486$04e7a560$04010164@LIAH>
Message-ID: <20080111210954.GX13357@solar.trillke>

Hi Sol, 

could you maybe edit 

    py/execnet/gateway.py 

in line 29, enabling the writing to the debug file? 
and try the example and send the content 
of the created debug file(s) here? 

Could you also see what ">>> gw" gives before 
channel.receive() is called? 

best, 

holger

On Fri, Jan 11, 2008 at 14:13 -0500, Sol Simpson wrote:
> Hi holger,
> 
> Thanks for the reply.
> 
> Print gw:
> 
> <PopenGateway receiving/sending (0 active channels)>
> 
> Print: gw.remote_exec("channel.send(42)").receive()
> 
> Hangs like before.
> 
> I am running 0.9.0, compiled using setup.py
> 
> I have tried with stackless python 2.5.1 and standard python 2.5.1.
> 
> Please let me know fi there is something else I can try.
> 
> Thanks again,
> 
> Sol Simpson
> SR Research Ltd.
> 
> -----Original Message-----
> From: holger krekel [mailto:holger at merlinux.de] 
> Sent: January 11, 2008 12:00 PM
> To: Sol Simpson
> Cc: py-dev at codespeak.net
> Subject: Re: [py-dev] issues running py.execnet
> 
> Hi Sol, 
> 
> i tried the example with the 0.9.0 py release on my Windows XP box
> with Python 2.5.1 - works for me. 
> 
> are you also using 0.9.0? 
> 
> Could you give me the output of
>     
>     >>> gw
> 
> and
> 
>     >>> gw.remote_exec("channel.send(42)").receive()
> 
> ?
> 
> best, 
> 
> holger
> 
> On Thu, Jan 10, 2008 at 16:53 -0500, Sol Simpson wrote:
> > I'm trying to test out py.execnet running one of the examples:
> > 
> >  
> > 
> > import py
> > 
> > gw = py.execnet.PopenGateway()
> > 
> > channel = gw.remote_exec("""
> > 
> >             import os
> > 
> >             channel.send(os.getpid())
> > 
> >             """)
> > 
> > remote_pid = channel.receive()
> > 
> > print remote_pid != py.std.os.getpid()
> > 
> >  
> > 
> > The issue is that the program hangs on the channel.receive() call. In task
> > manager I can see that a second python.exe has been launched, but that is
> > it. The only way to exit the app is to kill one of the python.exe in the
> > task manager.
> > 
> >  
> > 
> > Any insight would be very helpful.
> > 
> >  
> > 
> > I'm running python 2.5.1 on Windows XP SP2.
> > 
> >  
> > 
> > Thank you,
> > 
> >  
> > 
> > Sol
> > 
> >  
> > 
> 
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> 
> 
> -- 
> merlinux GmbH       
> http://merlinux.de  
> 

-- 
merlinux GmbH       
http://merlinux.de  

From holger at merlinux.de  Fri Jan 11 22:27:48 2008
From: holger at merlinux.de (holger krekel)
Date: Fri, 11 Jan 2008 22:27:48 +0100
Subject: [py-dev] issues running py.execnet
In-Reply-To: <002701c85498$1de5c9e0$04010164@LIAH>
References: <000301c853d3$48dac1c0$04010164@LIAH>
	<20080111165934.GV13357@solar.trillke>
	<001901c85486$04e7a560$04010164@LIAH>
	<20080111210954.GX13357@solar.trillke>
	<002701c85498$1de5c9e0$04010164@LIAH>
Message-ID: <20080111212748.GY13357@solar.trillke>

Hi Sol (i am adding py-dev again to CC), 

On Fri, Jan 11, 2008 at 16:22 -0500, Sol Simpson wrote:
> If I put a gw.exit() at the end of the script, then it ends OK.
> 
> Is that all it was, that I did not have and exit at the end of the script?

ah - i initially thought that the "channel.receive()" call 
itself hang and not the try to leave the python interpreter.

Indeed, you should "gw.exit()" - the automatic cleanup semantics 
(at process exit) are not reliable yet throughout python versions, 
i am afraid. 

best,

holger

> -----Original Message-----
> From: holger krekel [mailto:holger at merlinux.de] 
> Sent: January 11, 2008 4:10 PM
> To: Sol Simpson
> Cc: py-dev at codespeak.net
> Subject: Re: [py-dev] issues running py.execnet
> 
> Hi Sol, 
> 
> could you maybe edit 
> 
>     py/execnet/gateway.py 
> 
> in line 29, enabling the writing to the debug file? 
> and try the example and send the content 
> of the created debug file(s) here? 
> 
> Could you also see what ">>> gw" gives before 
> channel.receive() is called? 
> 
> best, 
> 
> holger
> 
> On Fri, Jan 11, 2008 at 14:13 -0500, Sol Simpson wrote:
> > Hi holger,
> > 
> > Thanks for the reply.
> > 
> > Print gw:
> > 
> > <PopenGateway receiving/sending (0 active channels)>
> > 
> > Print: gw.remote_exec("channel.send(42)").receive()
> > 
> > Hangs like before.
> > 
> > I am running 0.9.0, compiled using setup.py
> > 
> > I have tried with stackless python 2.5.1 and standard python 2.5.1.
> > 
> > Please let me know fi there is something else I can try.
> > 
> > Thanks again,
> > 
> > Sol Simpson
> > SR Research Ltd.
> > 
> > -----Original Message-----
> > From: holger krekel [mailto:holger at merlinux.de] 
> > Sent: January 11, 2008 12:00 PM
> > To: Sol Simpson
> > Cc: py-dev at codespeak.net
> > Subject: Re: [py-dev] issues running py.execnet
> > 
> > Hi Sol, 
> > 
> > i tried the example with the 0.9.0 py release on my Windows XP box
> > with Python 2.5.1 - works for me. 
> > 
> > are you also using 0.9.0? 
> > 
> > Could you give me the output of
> >     
> >     >>> gw
> > 
> > and
> > 
> >     >>> gw.remote_exec("channel.send(42)").receive()
> > 
> > ?
> > 
> > best, 
> > 
> > holger
> > 
> > On Thu, Jan 10, 2008 at 16:53 -0500, Sol Simpson wrote:
> > > I'm trying to test out py.execnet running one of the examples:
> > > 
> > >  
> > > 
> > > import py
> > > 
> > > gw = py.execnet.PopenGateway()
> > > 
> > > channel = gw.remote_exec("""
> > > 
> > >             import os
> > > 
> > >             channel.send(os.getpid())
> > > 
> > >             """)
> > > 
> > > remote_pid = channel.receive()
> > > 
> > > print remote_pid != py.std.os.getpid()
> > > 
> > >  
> > > 
> > > The issue is that the program hangs on the channel.receive() call. In
> task
> > > manager I can see that a second python.exe has been launched, but that
> is
> > > it. The only way to exit the app is to kill one of the python.exe in the
> > > task manager.
> > > 
> > >  
> > > 
> > > Any insight would be very helpful.
> > > 
> > >  
> > > 
> > > I'm running python 2.5.1 on Windows XP SP2.
> > > 
> > >  
> > > 
> > > Thank you,
> > > 
> > >  
> > > 
> > > Sol
> > > 
> > >  
> > > 
> > 
> > > _______________________________________________
> > > py-dev mailing list
> > > py-dev at codespeak.net
> > > http://codespeak.net/mailman/listinfo/py-dev
> > 
> > 
> > -- 
> > merlinux GmbH       
> > http://merlinux.de  
> > 
> 
> -- 
> merlinux GmbH       
> http://merlinux.de  
> 

-- 
merlinux GmbH       
http://merlinux.de  

From sol at sr-research.com  Fri Jan 11 22:33:23 2008
From: sol at sr-research.com (Sol Simpson)
Date: Fri, 11 Jan 2008 16:33:23 -0500
Subject: [py-dev] issues running py.execnet
In-Reply-To: <20080111212748.GY13357@solar.trillke>
References: <000301c853d3$48dac1c0$04010164@LIAH>
	<20080111165934.GV13357@solar.trillke>
	<001901c85486$04e7a560$04010164@LIAH>
	<20080111210954.GX13357@solar.trillke>
	<002701c85498$1de5c9e0$04010164@LIAH>
	<20080111212748.GY13357@solar.trillke>
Message-ID: <002b01c85499$9cd4a450$04010164@LIAH>

Thanks very much. 

Sol Simpson
SR Research Ltd.


-----Original Message-----
From: holger krekel [mailto:holger at merlinux.de] 
Sent: January 11, 2008 4:28 PM
To: Sol Simpson
Cc: py-dev at codespeak.net
Subject: Re: [py-dev] issues running py.execnet

Hi Sol (i am adding py-dev again to CC), 

On Fri, Jan 11, 2008 at 16:22 -0500, Sol Simpson wrote:
> If I put a gw.exit() at the end of the script, then it ends OK.
> 
> Is that all it was, that I did not have and exit at the end of the script?

ah - i initially thought that the "channel.receive()" call 
itself hang and not the try to leave the python interpreter.

Indeed, you should "gw.exit()" - the automatic cleanup semantics 
(at process exit) are not reliable yet throughout python versions, 
i am afraid. 

best,

holger

> -----Original Message-----
> From: holger krekel [mailto:holger at merlinux.de] 
> Sent: January 11, 2008 4:10 PM
> To: Sol Simpson
> Cc: py-dev at codespeak.net
> Subject: Re: [py-dev] issues running py.execnet
> 
> Hi Sol, 
> 
> could you maybe edit 
> 
>     py/execnet/gateway.py 
> 
> in line 29, enabling the writing to the debug file? 
> and try the example and send the content 
> of the created debug file(s) here? 
> 
> Could you also see what ">>> gw" gives before 
> channel.receive() is called? 
> 
> best, 
> 
> holger
> 
> On Fri, Jan 11, 2008 at 14:13 -0500, Sol Simpson wrote:
> > Hi holger,
> > 
> > Thanks for the reply.
> > 
> > Print gw:
> > 
> > <PopenGateway receiving/sending (0 active channels)>
> > 
> > Print: gw.remote_exec("channel.send(42)").receive()
> > 
> > Hangs like before.
> > 
> > I am running 0.9.0, compiled using setup.py
> > 
> > I have tried with stackless python 2.5.1 and standard python 2.5.1.
> > 
> > Please let me know fi there is something else I can try.
> > 
> > Thanks again,
> > 
> > Sol Simpson
> > SR Research Ltd.
> > 
> > -----Original Message-----
> > From: holger krekel [mailto:holger at merlinux.de] 
> > Sent: January 11, 2008 12:00 PM
> > To: Sol Simpson
> > Cc: py-dev at codespeak.net
> > Subject: Re: [py-dev] issues running py.execnet
> > 
> > Hi Sol, 
> > 
> > i tried the example with the 0.9.0 py release on my Windows XP box
> > with Python 2.5.1 - works for me. 
> > 
> > are you also using 0.9.0? 
> > 
> > Could you give me the output of
> >     
> >     >>> gw
> > 
> > and
> > 
> >     >>> gw.remote_exec("channel.send(42)").receive()
> > 
> > ?
> > 
> > best, 
> > 
> > holger
> > 
> > On Thu, Jan 10, 2008 at 16:53 -0500, Sol Simpson wrote:
> > > I'm trying to test out py.execnet running one of the examples:
> > > 
> > >  
> > > 
> > > import py
> > > 
> > > gw = py.execnet.PopenGateway()
> > > 
> > > channel = gw.remote_exec("""
> > > 
> > >             import os
> > > 
> > >             channel.send(os.getpid())
> > > 
> > >             """)
> > > 
> > > remote_pid = channel.receive()
> > > 
> > > print remote_pid != py.std.os.getpid()
> > > 
> > >  
> > > 
> > > The issue is that the program hangs on the channel.receive() call. In
> task
> > > manager I can see that a second python.exe has been launched, but that
> is
> > > it. The only way to exit the app is to kill one of the python.exe in
the
> > > task manager.
> > > 
> > >  
> > > 
> > > Any insight would be very helpful.
> > > 
> > >  
> > > 
> > > I'm running python 2.5.1 on Windows XP SP2.
> > > 
> > >  
> > > 
> > > Thank you,
> > > 
> > >  
> > > 
> > > Sol
> > > 
> > >  
> > > 
> > 
> > > _______________________________________________
> > > py-dev mailing list
> > > py-dev at codespeak.net
> > > http://codespeak.net/mailman/listinfo/py-dev
> > 
> > 
> > -- 
> > merlinux GmbH       
> > http://merlinux.de  
> > 
> 
> -- 
> merlinux GmbH       
> http://merlinux.de  
> 

-- 
merlinux GmbH       
http://merlinux.de  


From holger at merlinux.de  Sat Jan 26 13:39:08 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 26 Jan 2008 13:39:08 +0100
Subject: [py-dev] towards 1.0 / code URLS using py.test?
Message-ID: <20080126123908.GE1337@solar.trillke>

Hey everybody, 

as some of you already know i'd like to get a py lib/py.test 1.0 out 
in February.  IOW, my sabbatical time which i took after the heavy last EU 
period of PyPy developments mid last year ... is over and i am slowly 
getting back into gear.  

Yesterday, i merged Maciej Fijalkowski's branch into py/trunk which 
unified objects used for distributed and in-process testing.  
I am going to refine the architecture further.  I generally try to 
keep track here: http://codespeak.net/svn/py/trunk/py/doc/TODO.txt 

How could you help with 1.0?  

For starters, it'd be great if you mail me URLs of 
code or projects using py.test and/or point to custom 
conftest.py's (py.test's extension mechanism).  

Feel free to also mail me your favourite annoyance or feature
wish along ... or point to ones from other tools.  This all
increases chances that 1.0 will work to your expectations :) 

I could use contributions or help (or sometimes just hints) in 
the following particular areas: 

- integrating py.test with Twisted 
- packaging for debian, setuptools
- unix/windows cross-platform communication and process
  deployment 

Please feel free to join the #pylib channel on freenode where you 
see commits to the code base and have me and a few other contributors 
hanging out ...  i am happy to discuss and answer questions there! 

I am also particularly interested in collaboration with 
other testing tool authors - let's work on improving everyone's 
testing experiences and on world wide code quality! :) 

best & cheers, 

holger

-- 
py.test: http://pytest.org 
py lib: http://pylib.org 
PyPy: http://codespeak.net/pypy 
merlinux GmbH: http://merlinux.de  

From grig at gheorghiu.net  Sat Jan 26 17:30:51 2008
From: grig at gheorghiu.net (Grig Gheorghiu)
Date: Sat, 26 Jan 2008 08:30:51 -0800 (PST)
Subject: [py-dev] [TIP] towards 1.0 / code URLS using py.test?
In-Reply-To: <20080126123908.GE1337@solar.trillke>
Message-ID: <467999.47168.qm@web54502.mail.re2.yahoo.com>

--- holger krekel <holger at merlinux.de> wrote:

> Hey everybody, 
> 
> 
> Feel free to also mail me your favourite annoyance or feature
> wish along ... or point to ones from other tools.  This all
> increases chances that 1.0 will work to your expectations :) 
> 
> I could use contributions or help (or sometimes just hints) in 
> the following particular areas: 
> 
> - integrating py.test with Twisted 
> - packaging for debian, setuptools
> - unix/windows cross-platform communication and process
>   deployment 
> 

Hi, Holger!

My main request for py.test would be #2 in your list above. I'd like to
be able to say 'easy_install py.test' and be done. From what I see in
the Python community, the more a tool can be easily deployed and
upgraded, and the more it integrates with other standard tools (such as
setuptools) -- the better its chances of being used on a large scale.

Grig



From beacybooks at bigpond.com  Sat Jan 26 23:34:20 2008
From: beacybooks at bigpond.com (Tom Harris)
Date: Sun, 27 Jan 2008 09:34:20 +1100
Subject: [py-dev] towards 1.0 / code URLS using py.test?
In-Reply-To: <20080126123908.GE1337@solar.trillke>
References: <20080126123908.GE1337@solar.trillke>
Message-ID: <479BB56C.5000902@bigpond.com>

I use py.test for testing embedded systems, and I find that I use 
generative tests a lot. Some means of running setup/teardown methods for 
_each_ test in a generative test would be very useful, I have a few 
ideas for syntax, but none for implementation.

Also I second the request for easy deployment of py.test, as I never use 
the other components of py.* there could even be a distribution with 
these removed.

Tom Harris BeacyBooks <beacybooks at bigpond.com>



holger krekel wrote:

>Hey everybody, 
>
>as some of you already know i'd like to get a py lib/py.test 1.0 out 
>in February.  IOW, my sabbatical time which i took after the heavy last EU 
>period of PyPy developments mid last year ... is over and i am slowly 
>getting back into gear.  
>
>Yesterday, i merged Maciej Fijalkowski's branch into py/trunk which 
>unified objects used for distributed and in-process testing.  
>I am going to refine the architecture further.  I generally try to 
>keep track here: http://codespeak.net/svn/py/trunk/py/doc/TODO.txt 
>
>How could you help with 1.0?  
>
>For starters, it'd be great if you mail me URLs of 
>code or projects using py.test and/or point to custom 
>conftest.py's (py.test's extension mechanism).  
>
>Feel free to also mail me your favourite annoyance or feature
>wish along ... or point to ones from other tools.  This all
>increases chances that 1.0 will work to your expectations :) 
>
>I could use contributions or help (or sometimes just hints) in 
>the following particular areas: 
>
>- integrating py.test with Twisted 
>- packaging for debian, setuptools
>- unix/windows cross-platform communication and process
>  deployment 
>
>Please feel free to join the #pylib channel on freenode where you 
>see commits to the code base and have me and a few other contributors 
>hanging out ...  i am happy to discuss and answer questions there! 
>
>I am also particularly interested in collaboration with 
>other testing tool authors - let's work on improving everyone's 
>testing experiences and on world wide code quality! :) 
>
>best & cheers, 
>
>holger
>
>  
>

From holger at merlinux.de  Sun Jan 27 00:49:44 2008
From: holger at merlinux.de (holger krekel)
Date: Sun, 27 Jan 2008 00:49:44 +0100
Subject: [py-dev] towards 1.0 / code URLS using py.test?
In-Reply-To: <479BB56C.5000902@bigpond.com>
References: <20080126123908.GE1337@solar.trillke>
	<479BB56C.5000902@bigpond.com>
Message-ID: <20080126234944.GH1337@solar.trillke>

Hi Tom, 

On Sun, Jan 27, 2008 at 09:34 +1100, Tom Harris wrote:
> I use py.test for testing embedded systems, and I find that I use 
> generative tests a lot. Some means of running setup/teardown methods for 
> _each_ test in a generative test would be very useful, I have a few 
> ideas for syntax, but none for implementation.

i'd like to think more about generative tests and particularly
their implementation but it's likely out of 1.0 scope.  
But Feel free to post considerations/ideas about generative tests
and how to syntactically express them! 

> Also I second the request for easy deployment of py.test, as I never use 
> the other components of py.* there could even be a distribution with 
> these removed.

py.test itself internally uses many of the py lib's components
(and actually often triggered their development).  

Regarding your usage - in case you have a publically accessible
code base please point me to it. 

best, 

holger

> Tom Harris BeacyBooks <beacybooks at bigpond.com>
> 
> 
> 
> holger krekel wrote:
> 
> >Hey everybody, 
> >
> >as some of you already know i'd like to get a py lib/py.test 1.0 out 
> >in February.  IOW, my sabbatical time which i took after the heavy last EU 
> >period of PyPy developments mid last year ... is over and i am slowly 
> >getting back into gear.  
> >
> >Yesterday, i merged Maciej Fijalkowski's branch into py/trunk which 
> >unified objects used for distributed and in-process testing.  
> >I am going to refine the architecture further.  I generally try to 
> >keep track here: http://codespeak.net/svn/py/trunk/py/doc/TODO.txt 
> >
> >How could you help with 1.0?  
> >
> >For starters, it'd be great if you mail me URLs of 
> >code or projects using py.test and/or point to custom 
> >conftest.py's (py.test's extension mechanism).  
> >
> >Feel free to also mail me your favourite annoyance or feature
> >wish along ... or point to ones from other tools.  This all
> >increases chances that 1.0 will work to your expectations :) 
> >
> >I could use contributions or help (or sometimes just hints) in 
> >the following particular areas: 
> >
> >- integrating py.test with Twisted 
> >- packaging for debian, setuptools
> >- unix/windows cross-platform communication and process
> >  deployment 
> >
> >Please feel free to join the #pylib channel on freenode where you 
> >see commits to the code base and have me and a few other contributors 
> >hanging out ...  i am happy to discuss and answer questions there! 
> >
> >I am also particularly interested in collaboration with 
> >other testing tool authors - let's work on improving everyone's 
> >testing experiences and on world wide code quality! :) 
> >
> >best & cheers, 
> >
> >holger
> >
> >  
> >
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
py.test: http://pytest.org 
py lib: http://pylib.org 
PyPy: http://codespeak.net/pypy 
merlinux GmbH: http://merlinux.de 

From johnny at johnnydebris.net  Sun Jan 27 10:48:18 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Sun, 27 Jan 2008 10:48:18 +0100
Subject: [py-dev] towards 1.0 / code URLS using py.test?
In-Reply-To: <20080126123908.GE1337@solar.trillke>
References: <20080126123908.GE1337@solar.trillke>
Message-ID: <479C5362.7020600@johnnydebris.net>

holger krekel wrote:
> IOW, my sabbatical time which i took after the heavy last EU 
> period of PyPy developments mid last year ... is over and i am slowly 
> getting back into gear.  
>
>   
Welcome back!

> For starters, it'd be great if you mail me URLs of 
> code or projects using py.test and/or point to custom 
> conftest.py's (py.test's extension mechanism).  
>
>   
I wrote a couple of conftests, one which executes unittest.py's TestCase 
instances, and one which runs JavaScript tests using Spidermonkey (the 
latter as part of a set of JS libs to handle common issues in JS and 
browsers):

http://johnnydebris.net/svn/projects/py_unittest/ - unittest integration

http://johnnydebris.net/svn/projects/jsbase/ - the base lib with 
conftest (and some implementations of assert* functions)

Also, I'd like to join development a bit early februari (is a release 
date set already?), I'll make sure to be on #pylib around that time...

Cheers,

Guido

From holger at merlinux.de  Sun Jan 27 22:23:41 2008
From: holger at merlinux.de (holger krekel)
Date: Sun, 27 Jan 2008 22:23:41 +0100
Subject: [py-dev] [TIP] towards 1.0 / code URLS using py.test?
In-Reply-To: <467999.47168.qm@web54502.mail.re2.yahoo.com>
References: <20080126123908.GE1337@solar.trillke>
	<467999.47168.qm@web54502.mail.re2.yahoo.com>
Message-ID: <20080127212341.GM1337@solar.trillke>

Hi Grig! 

On Sat, Jan 26, 2008 at 08:30 -0800, Grig Gheorghiu wrote:
> --- holger krekel <holger at merlinux.de> wrote:
> 
> > Hey everybody, 
> > 
> > 
> > Feel free to also mail me your favourite annoyance or feature
> > wish along ... or point to ones from other tools.  This all
> > increases chances that 1.0 will work to your expectations :) 
> > 
> > I could use contributions or help (or sometimes just hints) in 
> > the following particular areas: 
> > 
> > - integrating py.test with Twisted 
> > - packaging for debian, setuptools
> > - unix/windows cross-platform communication and process
> >   deployment 
> > 
> 
> Hi, Holger!
> 
> My main request for py.test would be #2 in your list above. I'd like to
> be able to say 'easy_install py.test' and be done. From what I see in
> the Python community, the more a tool can be easily deployed and
> upgraded, and the more it integrates with other standard tools (such as
> setuptools) -- the better its chances of being used on a large scale.

surely, you are right.  What happens if you type 

    easy_install py

?  For me this works and installs py.test (which is part of the py lib). 

Is it possible to have something like an alias so that when people 
type "easy_install pytest" or so it also installs the right thing? 

best & cheers, 

holger

From schmir at gmail.com  Mon Jan 28 05:53:23 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Mon, 28 Jan 2008 05:53:23 +0100
Subject: [py-dev] towards 1.0 / code URLS using py.test?
In-Reply-To: <20080126123908.GE1337@solar.trillke>
References: <20080126123908.GE1337@solar.trillke>
Message-ID: <932f8baf0801272053p6607671flccf6902f412c1451@mail.gmail.com>

On Jan 26, 2008 1:39 PM, holger krekel <holger at merlinux.de> wrote:

>
> I could use contributions or help (or sometimes just hints) in
> the following particular areas:
>
> - integrating py.test with Twisted


http://systemexit.de/repo/py.test.twisted/ contains a mercurial repository,
which makes testing code running under the twisted reactor possible. (I've
already asked about integrating it into the py library).

Regards,
- Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20080128/70f42706/attachment.htm 

From holger at merlinux.de  Mon Jan 28 11:09:44 2008
From: holger at merlinux.de (holger krekel)
Date: Mon, 28 Jan 2008 11:09:44 +0100
Subject: [py-dev] towards 1.0 / code URLS using py.test?
In-Reply-To: <932f8baf0801272053p6607671flccf6902f412c1451@mail.gmail.com>
References: <20080126123908.GE1337@solar.trillke>
	<932f8baf0801272053p6607671flccf6902f412c1451@mail.gmail.com>
Message-ID: <20080128100944.GN1337@solar.trillke>

Hi Ralf, 

On Mon, Jan 28, 2008 at 05:53 +0100, Ralf Schmitt wrote:
> On Jan 26, 2008 1:39 PM, holger krekel <holger at merlinux.de> wrote:
> >
> > I could use contributions or help (or sometimes just hints) in
> > the following particular areas:
> >
> > - integrating py.test with Twisted
> 
> 
> http://systemexit.de/repo/py.test.twisted/ contains a mercurial repository,
> which makes testing code running under the twisted reactor possible. (I've
> already asked about integrating it into the py library).

Yip, in fact i wanted to get back to you - thanks for answering here. 
Your integration looks suprisingly small! I wasn't aware that
using greenlets with twisted works that well, to be honest.  
Definitely makes sense to include this technique - i think we'll 
need to sort out some more issues like interaction with distributed
testing, doctests, ReST tests etc.  (on py-dev). 

best & thanks, 

holger

-- 
py.test: http://pytest.org 
py lib: http://pylib.org 
PyPy: http://codespeak.net/pypy 
merlinux GmbH: http://merlinux.de 

From exarkun at divmod.com  Sat Jan 26 15:27:09 2008
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Sat, 26 Jan 2008 09:27:09 -0500
Subject: [py-dev] [TIP] towards 1.0 / code URLS using py.test?
In-Reply-To: <20080126123908.GE1337@solar.trillke>
Message-ID: <20080126142709.6859.1607151009.divmod.quotient.1026@ohm>

On Sat, 26 Jan 2008 13:39:08 +0100, holger krekel <holger at merlinux.de> wrote:
>Hey everybody,
>
>as some of you already know i'd like to get a py lib/py.test 1.0 out
>in February.  IOW, my sabbatical time which i took after the heavy last EU
>period of PyPy developments mid last year ... is over and i am slowly
>getting back into gear.

I hope you had an enjoyable and refreshing sabbatical.  Welcome back. :)

>
>Yesterday, i merged Maciej Fijalkowski's branch into py/trunk which
>unified objects used for distributed and in-process testing.
>I am going to refine the architecture further.  I generally try to
>keep track here: http://codespeak.net/svn/py/trunk/py/doc/TODO.txt

Cool.  This means that if I have been using the reporter-merge branch,
I can just use trunk now, right?

>
>How could you help with 1.0?
>
> [snip]
>
>I could use contributions or help (or sometimes just hints) in
>the following particular areas:
>
>- integrating py.test with Twisted

Do you have any particular ideas or goals for this?

Jean-Paul

From exarkun at divmod.com  Mon Jan 28 16:09:38 2008
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Mon, 28 Jan 2008 10:09:38 -0500
Subject: [py-dev] [TIP]  towards 1.0 / code URLS using py.test?
In-Reply-To: <20080128100944.GN1337@solar.trillke>
Message-ID: <20080128150938.6859.686086216.divmod.quotient.1802@ohm>

On Mon, 28 Jan 2008 11:09:44 +0100, holger krekel <holger at merlinux.de> wrote:
>Hi Ralf,
>
>On Mon, Jan 28, 2008 at 05:53 +0100, Ralf Schmitt wrote:
>> On Jan 26, 2008 1:39 PM, holger krekel <holger at merlinux.de> wrote:
>> >
>> > I could use contributions or help (or sometimes just hints) in
>> > the following particular areas:
>> >
>> > - integrating py.test with Twisted
>>
>>
>> http://systemexit.de/repo/py.test.twisted/ contains a mercurial repository,
>> which makes testing code running under the twisted reactor possible. (I've
>> already asked about integrating it into the py library).

Is it intentional that this integration busy-loops, guaranteeing 100% CPU
usage for the entire test-run?

Jean-Paul

From grig at gheorghiu.net  Mon Jan 28 20:49:25 2008
From: grig at gheorghiu.net (Grig Gheorghiu)
Date: Mon, 28 Jan 2008 11:49:25 -0800 (PST)
Subject: [py-dev] [TIP] towards 1.0 / code URLS using py.test?
In-Reply-To: <20080127212341.GM1337@solar.trillke>
Message-ID: <336645.87454.qm@web54501.mail.re2.yahoo.com>

--- holger krekel <holger at merlinux.de> wrote:

> What happens if you type 
> 
>     easy_install py
> 
> ?  For me this works and installs py.test (which is part of the py
> lib). 
> 

You're right, it works for me too. I wasn't aware that it's already
been setuptools-ified. That's good news!

> Is it possible to have something like an alias so that when people 
> type "easy_install pytest" or so it also installs the right thing? 
> 

Not sure, I'm not really a setuptools expert.

Grig

From schmir at gmail.com  Tue Jan 29 07:02:28 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Tue, 29 Jan 2008 07:02:28 +0100
Subject: [py-dev] [TIP]  towards 1.0 / code URLS using py.test?
In-Reply-To: <20080128150938.6859.686086216.divmod.quotient.1802@ohm>
References: <20080128100944.GN1337@solar.trillke>
	<20080128150938.6859.686086216.divmod.quotient.1802@ohm>
Message-ID: <932f8baf0801282202s1f9fa7e3l717e100d41f08dda@mail.gmail.com>

On Jan 28, 2008 4:09 PM, Jean-Paul Calderone <exarkun at divmod.com> wrote:

> On Mon, 28 Jan 2008 11:09:44 +0100, holger krekel <holger at merlinux.de>
> wrote:
> >Hi Ralf,
> >
> >On Mon, Jan 28, 2008 at 05:53 +0100, Ralf Schmitt wrote:
> >> On Jan 26, 2008 1:39 PM, holger krekel <holger at merlinux.de> wrote:
> >> >
> >> > I could use contributions or help (or sometimes just hints) in
> >> > the following particular areas:
> >> >
> >> > - integrating py.test with Twisted
> >>
> >>
> >> http://systemexit.de/repo/py.test.twisted/ contains a mercurial
> repository,
> >> which makes testing code running under the twisted reactor possible.
> (I've
> >> already asked about integrating it into the py library).
>
> Is it intentional that this integration busy-loops, guaranteeing 100% CPU
> usage for the entire test-run?
>

Why do you think so? Apparently this isn't true on my machine:

~/py.test.twisted/ cat test_some.py                                 ralf at redok
#! /usr/bin/env py.test.twisted

from twisted.internet import defer, reactor
from twisted.python import failure
from twisted.python import log

def test_deferred():
    d = defer.Deferred()
    def done():
        log.msg("done")
        d.callback(None)

    reactor.callLater(25, done)
    log.msg("Returning %r" % (d,))
    return d

def test_defer_fail():
    def fun():
        log.msg("provoking NameError")
        rsdfg
    return defer.maybeDeferred(fun)
~/py.test.twisted/ time ./py.test.twisted test_some.py              ralf at redok
2008-01-29 07:01:14+0100 [-] Log opened.
============================= test process starts
==============================
executable:   /home/ralf/py25/bin/python  (2.5.2-alpha-0)
using py lib: /home/ralf/py25/lib/python2.5/site-packages/py-0.9.0-py2.5.egg/py
<rev unknown>

test_some.py[2] .F

________________________________________________________________________________
_________________________ entrypoint: test_defer_fail
__________________________

    def fun():
        log.msg("provoking NameError")
E       rsdfg
>       NameError: global name 'rsdfg' is not defined

[/home/ralf/py.test.twisted/test_some.py:20]
- - - - - - - - - - -  test_defer_fail: recorded stdout - - - - - - - - - -
- -
2008-01-29 07:01:39+0100 [-] provoking NameError

________________________________________________________________________________
============= tests finished: 1 passed, 1 failed in 25.00 seconds
==============
2008-01-29 07:01:39+0100 [-] Main loop terminated.
./py.test.twisted test_some.py  0.22s user 0.06s system 1% cpu 25.278 total
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20080129/b2f4e71c/attachment.htm 

From exarkun at divmod.com  Tue Jan 29 15:09:07 2008
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Tue, 29 Jan 2008 09:09:07 -0500
Subject: [py-dev] [TIP]  towards 1.0 / code URLS using py.test?
In-Reply-To: <932f8baf0801282202s1f9fa7e3l717e100d41f08dda@mail.gmail.com>
Message-ID: <20080129140907.6859.19712609.divmod.quotient.2293@ohm>

On Tue, 29 Jan 2008 07:02:28 +0100, Ralf Schmitt <schmir at gmail.com> wrote:
>On Jan 28, 2008 4:09 PM, Jean-Paul Calderone <exarkun at divmod.com> wrote:
>
>> [snip]
>>
>> Is it intentional that this integration busy-loops, guaranteeing 100% CPU
>> usage for the entire test-run?
>>
>
>Why do you think so? Apparently this isn't true on my machine:
>
> [snip]
>
>2008-01-29 07:01:39+0100 [-] Main loop terminated.
>./py.test.twisted test_some.py  0.22s user 0.06s system 1% cpu 25.278 total
>

You're right, of course.  I misread the way Deferreds were handled.  Sorry
for the noise. :)

Jean-Paul

From rpk at mac.com  Thu Jan 31 22:29:35 2008
From: rpk at mac.com (Bob Kuehne)
Date: Thu, 31 Jan 2008 16:29:35 -0500
Subject: [py-dev] py.execnet: hang in channel.receive()
Message-ID: <FDEBD443-B48F-4188-AC1D-259B9C1F89A3@mac.com>

hi gang,

i first saw holger present py.execnet at pycon a few years back, and  
have been waiting to use this cool tool. so now i'm on it, and i've  
got a problem. i'm running this on two macs, both running os x 10.5.1.  
i've installed py via easy_install, so i've got a luverly egg, and  
here's my script that i'm trying to just test with:

--
import py
gw = py.execnet.SshGateway( "localhost" )
channel = gw.remote_exec( 'channel.send( [ [ False, True, False,  
0, ] ] )' )
print channel.receive()
channel.close()
gw.exit()
--

so, on mac numero 1, running python 2.5.1, i see the output i'd expect:

--
Python 2.5.1 (r251:54863, Oct  5 2007, 21:08:09)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import py
 >>> gw = py.execnet.SshGateway( "localhost" )
 >>> channel = gw.remote_exec( 'channel.send( [ [ False, True, False,  
0, ] ] )' )
 >>> print channel.receive()
[[False, True, False, 0]]
 >>> channel.close()
 >>> gw.exit()
--

but on another mac, also python 2.5.1, i see the same, but the  
'channel.receive()' is hung. if i break there (control-c), i get the  
following:

--
Python 2.5.1 (r251:54863, Oct  9 2007, 20:39:46)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import py
 >>> gw = py.execnet.SshGateway( "localhost" )
 >>> channel = gw.remote_exec( 'channel.send( [ [ False, True, False,  
0, ] ] )' )
 >>> print channel.receive()
^CKilled by signal 2.
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/Library/Python/2.5/site-packages/py-0.9.0-py2.5.egg/py/ 
execnet/channel.py", line 172, in receive
     x = queue.get()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/Queue.py", line 165, in get
     self.not_empty.wait()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/threading.py", line 214, in wait
     waiter.acquire()
KeyboardInterrupt
--

now, the question is what's different. and it's at this point that i  
wave my arms and go, wtf? i really don't know, but i'm wondering aloud  
if anyone else has seen this sort of behavior, and if so, what they  
might have encountered or changed to get it to be better behaved.

thanks,
bob



From holger at merlinux.de  Fri Feb  1 11:58:20 2008
From: holger at merlinux.de (holger krekel)
Date: Fri, 1 Feb 2008 11:58:20 +0100
Subject: [py-dev] "event" branch and architecture
Message-ID: <20080201105820.GC3020@solar.trillke>

Hi py-dev! 

i am currently hammering on the svn/py/branch/event branch [*]. 
The main intention is to modify py.test's internal architecture
towards using events and to base reporting and some internal 
processing on these events.  Here is the basic event loop
(exposed as py.event.Hub for now): 

    class Hub(list):
        """ General Event Hub """
        def notify(self, event):
            for subscriber in self:
                subscriber(event)

This is inspired by a talk from Jim Fulton about zope3's event loop - 
zope.event just contains a global list and a notify function like the above. 
However, i'd like to keep things more local for now (going global is
usually much easier than going local, to begin with and local state
is also nicer for TDD)

For py.test the upcoming event archicture should allow us to e.g.:

* have co-existing reporters e.g. one that writes test results 
  to an internal database and one that provides terminal reporting. 

* Or one terminal and one html-output reporter.  

* GUI based reporters (where we can easily route events to GUI loops) 

* Or a small plugin that allows to automatically copy 
  failure information to e.g. http://paste.pocoo.org/. 

* ... 

I am also using the event branch to do various cleanups and refactorings,
mainly i am aiming at refactoring distributed and remote testing
to share more code (and Events) with local testing.  I hope that 
in the end one can write a reporter that does not need to care 
(too much) how tests are/were distributed across machines.  

best & cheers, 

holger

[*] In fact i am working there in py/test2 - which is a branch itself of py/test. 
    I did this (with the help of the py/bin/_maketest2.py helper, btw) 
    in order to be able to use py.test for refactoring py.test. 
    Otherwise if i change files in py/test/ and try to run py.test it would 
    affect my very own test run, making TDD hard or impossible. 

--
Holger Krekel - freelance manager and programmer
merlinux GmbH: http://merlinux.de 
py.test: http://pytest.org 
py lib: http://pylib.org 
PyPy: http://codespeak.net/pypy 

From tav at espians.com  Fri Feb  1 12:21:20 2008
From: tav at espians.com (tav)
Date: Fri, 1 Feb 2008 11:21:20 +0000
Subject: [py-dev] "event" branch and architecture
In-Reply-To: <20080201105820.GC3020@solar.trillke>
References: <20080201105820.GC3020@solar.trillke>
Message-ID: <95d8c0810802010321h429ecc74r6a7015785a99ad9c@mail.gmail.com>

Hey Holger,

> i am currently hammering on the svn/py/branch/event branch [*].
> The main intention is to modify py.test's internal architecture
> towards using events and to base reporting and some internal
> processing on these events.

Whilst Zope's event system is nice in its simplicity, it suffers from
many faults once you go beyond the basic use cases. The easiest one to
explain is race conditions that take place with regards to nested
subscriptions. That is, when calling a subscriber/listener with an
event, if that action adds a new listener... and/or notifies the
Hub... you have a lot of pain to work around.

Now, throw in exceptions into that and *boom*, you have a rather messy
minefield.

Can I recommend using Trellis by any chance?

* http://peak.telecommunity.com/DevCenter/Trellis

It solves a lot of very difficult problems rather elegantly and the
core is just 450 lines of code!! Whilst the documentation is a tad
confusing, it does have a lot of it and some parts are written very
nicely.

-- 
hope-this-helps, tav
founder and ceo, esp metanational llp

plex:espians/tav | tav at espians.com | +44 (0) 7809 569 369

From holger at merlinux.de  Fri Feb  1 12:45:53 2008
From: holger at merlinux.de (holger krekel)
Date: Fri, 1 Feb 2008 12:45:53 +0100
Subject: [py-dev] "event" branch and architecture
In-Reply-To: <95d8c0810802010321h429ecc74r6a7015785a99ad9c@mail.gmail.com>
References: <20080201105820.GC3020@solar.trillke>
	<95d8c0810802010321h429ecc74r6a7015785a99ad9c@mail.gmail.com>
Message-ID: <20080201114553.GE3020@solar.trillke>

Hey tav! 

On Fri, Feb 01, 2008 at 11:21 +0000, tav wrote:
> Hey Holger,
> 
> > i am currently hammering on the svn/py/branch/event branch [*].
> > The main intention is to modify py.test's internal architecture
> > towards using events and to base reporting and some internal
> > processing on these events.
> 
> Whilst Zope's event system is nice in its simplicity, it suffers from
> many faults once you go beyond the basic use cases. The easiest one to
> explain is race conditions that take place with regards to nested
> subscriptions. That is, when calling a subscriber/listener with an
> event, if that action adds a new listener... and/or notifies the
> Hub... you have a lot of pain to work around.

I can see that triggering events nestedly can be problematic.
But I am not sure it is a problem for the upcoming py.test use cases and if so 
i think we could extend the hub's notify protocol to allow subscribers to 
return new events that are to trigger notification after the current run is through. 

> Now, throw in exceptions into that and *boom*, you have a rather messy
> minefield.

Well, subscribers need to take care for dealing with exceptions. 
We could do a "try-except" but then what do we do with the exception, anyway? 

For me, the beauty of the z3 event loop lies in the fact that every python 
programmer can understand easily what he is dealing with if 
wanting to have a subscriber (or notifier) participate. 

> Can I recommend using Trellis by any chance?

sure, you are welcome!  

> * http://peak.telecommunity.com/DevCenter/Trellis
> 
> It solves a lot of very difficult problems rather elegantly and the
> core is just 450 lines of code!! Whilst the documentation is a tad
> confusing, it does have a lot of it and some parts are written very
> nicely.

Introducing events for py.test particularly aims at *decoupling* things, 
also to allow for "plugin" based features.  Isn't Trellis rather
aiming at coupling things automatically? 

I haven't looked at the Trellis code (is it using other PEAK
code btw?) but from reading the web page i appears to me that
Trellis is a framework rather than a simple pattern - the py
lib avoids to do frameworkish things like introducing
subclassing requirements.  

best & cheers, 

holger

-- 
Holger Krekel - freelance manager and programmer 
merlinux GmbH: http://merlinux.de 
py.test: http://pytest.org 
py lib: http://pylib.org 
PyPy: http://codespeak.net/pypy 

From holger at merlinux.de  Fri Feb  1 22:57:05 2008
From: holger at merlinux.de (holger krekel)
Date: Fri, 1 Feb 2008 22:57:05 +0100
Subject: [py-dev] py.execnet: hang in channel.receive()
In-Reply-To: <FDEBD443-B48F-4188-AC1D-259B9C1F89A3@mac.com>
References: <FDEBD443-B48F-4188-AC1D-259B9C1F89A3@mac.com>
Message-ID: <20080201215705.GO3020@solar.trillke>

Hi Bob, 

could you checkout 

    http://codespeak.net/svn/pypy/branch/bugfix-0.9.0 

change to the checked out directory and perform your test below 
again?  This is a vanilla 0.9.0 with debugging info enabled.
It creates debug files in /tmp/execnet-debug-PROCESS-ID, one
for the client and for the spawned site.  Could you forward
the contents of these files? 

best, 

holger

On Thu, Jan 31, 2008 at 16:29 -0500, Bob Kuehne wrote:
> hi gang,
> 
> i first saw holger present py.execnet at pycon a few years back, and  
> have been waiting to use this cool tool. so now i'm on it, and i've  
> got a problem. i'm running this on two macs, both running os x 10.5.1.  
> i've installed py via easy_install, so i've got a luverly egg, and  
> here's my script that i'm trying to just test with:
> 
> --
> import py
> gw = py.execnet.SshGateway( "localhost" )
> channel = gw.remote_exec( 'channel.send( [ [ False, True, False,  
> 0, ] ] )' )
> print channel.receive()
> channel.close()
> gw.exit()
> --
> 
> so, on mac numero 1, running python 2.5.1, i see the output i'd expect:
> 
> --
> Python 2.5.1 (r251:54863, Oct  5 2007, 21:08:09)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import py
>  >>> gw = py.execnet.SshGateway( "localhost" )
>  >>> channel = gw.remote_exec( 'channel.send( [ [ False, True, False,  
> 0, ] ] )' )
>  >>> print channel.receive()
> [[False, True, False, 0]]
>  >>> channel.close()
>  >>> gw.exit()
> --
> 
> but on another mac, also python 2.5.1, i see the same, but the  
> 'channel.receive()' is hung. if i break there (control-c), i get the  
> following:
> 
> --
> Python 2.5.1 (r251:54863, Oct  9 2007, 20:39:46)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import py
>  >>> gw = py.execnet.SshGateway( "localhost" )
>  >>> channel = gw.remote_exec( 'channel.send( [ [ False, True, False,  
> 0, ] ] )' )
>  >>> print channel.receive()
> ^CKilled by signal 2.
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/Library/Python/2.5/site-packages/py-0.9.0-py2.5.egg/py/ 
> execnet/channel.py", line 172, in receive
>      x = queue.get()
>    File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/Queue.py", line 165, in get
>      self.not_empty.wait()
>    File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/threading.py", line 214, in wait
>      waiter.acquire()
> KeyboardInterrupt
> --
> 
> now, the question is what's different. and it's at this point that i  
> wave my arms and go, wtf? i really don't know, but i'm wondering aloud  
> if anyone else has seen this sort of behavior, and if so, what they  
> might have encountered or changed to get it to be better behaved.
> 
> thanks,
> bob
> 
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
Holger Krekel - freelance manager and programmer 
merlinux GmbH: http://merlinux.de 
py.test: http://pytest.org 
py lib: http://pylib.org 
PyPy: http://codespeak.net/pypy 

From brian at dorseys.org  Tue Feb  5 09:25:10 2008
From: brian at dorseys.org (Brian Dorsey)
Date: Tue, 5 Feb 2008 00:25:10 -0800
Subject: [py-dev] Is py lib advertising 'initpkg' ?
Message-ID: <66e877b70802050025s2d40b92cu9256fc1c1f08ca3e@mail.gmail.com>

I ran into this comp.lang.python post today:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/5a9580e76484f73/

Seems like initpkg might be a good solution for the poster... however,
I didn't see any reference to initpkg in any of the docs for py lib.
Is it intended to be an implementation detail, or a tool for others to
use?

Take care,
  -Brian

From holger at merlinux.de  Tue Feb  5 11:04:26 2008
From: holger at merlinux.de (holger krekel)
Date: Tue, 5 Feb 2008 11:04:26 +0100
Subject: [py-dev] Is py lib advertising 'initpkg' ?
In-Reply-To: <66e877b70802050025s2d40b92cu9256fc1c1f08ca3e@mail.gmail.com>
References: <66e877b70802050025s2d40b92cu9256fc1c1f08ca3e@mail.gmail.com>
Message-ID: <20080205100426.GH31519@solar.trillke>

Hi Brian! 

On Tue, Feb 05, 2008 at 00:25 -0800, Brian Dorsey wrote:
> I ran into this comp.lang.python post today:
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/5a9580e76484f73/
> 
> Seems like initpkg might be a good solution for the poster... however,
> I didn't see any reference to initpkg in any of the docs for py lib.
> Is it intended to be an implementation detail, or a tool for others to
> use?

good question! i very quickly skimmed the above (huge) thread. 
Indeed, the goal of separating a package's namespace organisation
from file locations on disk is a main motivation of py' initpkg. 

I am using initpkg in a couple of other projects with PKG/__init__.py containing: 

    from py import initpkg 
    initpkg("vadm", 
        ...
        exportdefs={
            ...
        }
    )

However, there indeed isn't documentation on using it.  
The initpkg mechanism is not using __import__ hooks
but subclasses the Module Class.  This also provides
lazy importing facilities and greatly reduces 
the need for "import" lines at the header of files. 
It also gives good control on which names exactly
are seen from package's users. 

IMO feel free to carefully point him to the mechanism
and invite him to to try out.  He may also subscribe here 
in order to discuss more or get support - i likely won't make
it to post to c.l.py myself. 

best, 

holger

From johnny at johnnydebris.net  Thu Feb  7 12:41:18 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Thu, 07 Feb 2008 12:41:18 +0100
Subject: [py-dev] py.path.svn* username and password support
Message-ID: <47AAEE5E.5030203@johnnydebris.net>

Hi!

Someone asked me if I want to implement support for passing a username 
and password to the py.path.svn* functionality, allowing the application 
to provide a username and pw both for svnurls and svnwcs. I've 
investigated SVN and the code a bit, and it looks like this can be done 
in a relatively nice way:

* svn seems to support command-line arguments for username and password, 
and also for telling it to not store auth information - with these 
arguments we can make sure the username/pw we provide are used, and not 
stored on the client

* there's a switch --non-interactive which we can then enable to make 
very sure applications don't hang on asking username/password or things 
like that (currently that can be a problem when using svnwc or svnurl in 
scripts)

I guess this would mean that for all operations that hit the server, the 
username and password arguments should be added. Perhaps it would be 
nice to have to provide it only on instantiation or something, although 
I fear that that will be harder to implement and use correctly in the 
situation of nested working copies (externals), etc.

I hope you guys like the idea of having this in the py lib, it sounds 
like a useful addition to me... If no-one minds, I'll start implementing 
in a couple of days, I'd like to have it done (and tested well, 
obviously) before the release, if possible...

Please let me know what you think.

Cheers,

Guido

From holger at merlinux.de  Thu Feb  7 19:06:39 2008
From: holger at merlinux.de (holger krekel)
Date: Thu, 7 Feb 2008 19:06:39 +0100
Subject: [py-dev] py.path.svn* username and password support
In-Reply-To: <47AAEE5E.5030203@johnnydebris.net>
References: <47AAEE5E.5030203@johnnydebris.net>
Message-ID: <20080207180638.GL17687@solar.trillke>

Hi Guido!

On Thu, Feb 07, 2008 at 12:41 +0100, Guido Wesdorp wrote:
> Hi!
> 
> Someone asked me if I want to implement support for passing a username 
> and password to the py.path.svn* functionality, allowing the application 
> to provide a username and pw both for svnurls and svnwcs. I've 
> investigated SVN and the code a bit, and it looks like this can be done 
> in a relatively nice way:
> 
> * svn seems to support command-line arguments for username and password, 
> and also for telling it to not store auth information - with these 
> arguments we can make sure the username/pw we provide are used, and not 
> stored on the client

why do you want to make sure this is not stored on the fs? 

> * there's a switch --non-interactive which we can then enable to make 
> very sure applications don't hang on asking username/password or things 
> like that (currently that can be a problem when using svnwc or svnurl in 
> scripts)

Sometimes py.path.svn* objects are used in interactively running 
scripts in which case it's ok that they ask for input. 
 
> I guess this would mean that for all operations that hit the server, the 
> username and password arguments should be added. Perhaps it would be 
> nice to have to provide it only on instantiation or something, although 
> I fear that that will be harder to implement and use correctly in the 
> situation of nested working copies (externals), etc.

Not sure about externals but i guess it's possible to allow for roughly
this to work: 

    wc = py.path.svnwc("somepath") 
    wc.checkout(URI, username=xxx, password=yyy)
    for subwcpath in wc.listdir():
        assert subwcpath.username # inherited auth information 
        assert subwcpath.password 
        ... 

However, 

    1) inheriting auth information may not always be what one wants 
    2) it's simpler to rely on the client FS storing auth data 

> I hope you guys like the idea of having this in the py lib, it sounds 
> like a useful addition to me... If no-one minds, I'll start implementing 
> in a couple of days, I'd like to have it done (and tested well, 
> obviously) before the release, if possible...

sure - let me note here that due to my prolonged ill-ish-ness (since last saturday now) 
and other surprising developments there may be no full 1.0 in Feb - in this
case i'd suggest to first go for 0.9.1, with just bugfixes and a few added feaures.
I hope that you and others could help with this. 

best, 

holger

From schmir at gmail.com  Thu Feb  7 19:27:36 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Thu, 7 Feb 2008 19:27:36 +0100
Subject: [py-dev] __package__ attribute used by python 2.6
Message-ID: <932f8baf0802071027h240d5431m8e97bd2eb5c5988b@mail.gmail.com>

Hi all,

__package__ is used extensively throughout the py lib.
Unfortunately it will also be used by python 2.6 (see
http://www.python.org/dev/peps/pep-0366/)
I have replaced all occurences of __package__ with __pypackage__ to make py
0.9.0 work with python 2.6.
I didn't run the testsuite but py.test seemed to work fine afterwards.
Any plans to fix it?

- Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20080207/ff7a342a/attachment.htm 

From holger at merlinux.de  Fri Feb  8 09:48:45 2008
From: holger at merlinux.de (holger krekel)
Date: Fri, 8 Feb 2008 09:48:45 +0100
Subject: [py-dev] __package__ attribute used by python 2.6
In-Reply-To: <932f8baf0802071027h240d5431m8e97bd2eb5c5988b@mail.gmail.com>
References: <932f8baf0802071027h240d5431m8e97bd2eb5c5988b@mail.gmail.com>
Message-ID: <20080208084845.GQ17687@solar.trillke>

Hi Ralf, 

On Thu, Feb 07, 2008 at 19:27 +0100, Ralf Schmitt wrote:
> Hi all,
> 
> __package__ is used extensively throughout the py lib.
> Unfortunately it will also be used by python 2.6 (see
> http://www.python.org/dev/peps/pep-0366/)
> I have replaced all occurences of __package__ with __pypackage__ to make py
> 0.9.0 work with python 2.6.
> I didn't run the testsuite but py.test seemed to work fine afterwards.
> Any plans to fix it?

i renamed it now to __pkg__ on 

    http://codespeak.net/svn/py/trunk 
    http://codespeak.net/svn/py/branch/bugfix-0.9.0 

best & thanks, 

holger

-- 
Holger Krekel - freelance manager and programmer 
merlinux GmbH: http://merlinux.de 
py.test: http://pytest.org 
py lib: http://pylib.org 
PyPy: http://codespeak.net/pypy 

From johnny at johnnydebris.net  Sat Feb  9 15:03:24 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Sat, 09 Feb 2008 15:03:24 +0100
Subject: [py-dev] 0.9.0:HEAD revision overview for 0.9.1 release
Message-ID: <47ADB2AC.3050207@johnnydebris.net>

Hi!

I went through all the checkins between r 38967 and the current HEAD and 
made lists of whether they were small bugfixes, refactorings and doc 
typos, or contain, or are part of, small or larger features. This 
hopefully helps when finding out what to port to the 0.9.1 branch for 
release...

The document is attached.

Cheers,

Guido
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 091_revisions.txt
Url: http://codespeak.net/pipermail/py-dev/attachments/20080209/405d93a2/attachment.txt 

From johnny at johnnydebris.net  Tue Feb 12 10:19:40 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Tue, 12 Feb 2008 10:19:40 +0100
Subject: [py-dev] Some ideas
Message-ID: <47B164AC.5040108@johnnydebris.net>

Hi!

I thought a bit about the authentication feature for py.path.svn*, and 
wrote my ideas in a small doc. The doc is attached - please discuss if 
you're interested...

Cheers,

Guido
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: auth.txt
Url: http://codespeak.net/pipermail/py-dev/attachments/20080212/71eb1d85/attachment-0001.txt 

From holger at merlinux.de  Tue Feb 12 12:09:15 2008
From: holger at merlinux.de (holger krekel)
Date: Tue, 12 Feb 2008 12:09:15 +0100
Subject: [py-dev] Some ideas
In-Reply-To: <47B164AC.5040108@johnnydebris.net>
References: <47B164AC.5040108@johnnydebris.net>
Message-ID: <20080212110915.GY17687@solar.trillke>

Hi Guido! 

On Tue, Feb 12, 2008 at 10:19 +0100, Guido Wesdorp wrote:
> I thought a bit about the authentication feature for py.path.svn*, and 
> wrote my ideas in a small doc. The doc is attached - please discuss if 
> you're interested...

nice way of doing this, thanks! 
 
> SVN authentication support
> ==========================
> 
> This document describes authentication support to both py.path.svnwc and
> py.path.svnurl (yet to be implemented). This should allow using the library in
> a completely automated situation, without having to provide the credentials
> interactively.
> 
> Current ideas for implementation
> --------------------------------
> 
> The credentials are passed to the constructor of the path objects, and are used
> (transparently) for every action that accesses the server. Also, when provided,
> they are passed recursively to all child objects created by methods such as
> join(), ensure(), etc.

Transparently inheriting AUTH info might sometimes not be desired
or be tricky, not sure.  I'd try this after all else is done (see below). 

> * Many new arguments required
> 
>   I think it's not very nice to have so many new arguments to the constructors,
>   and especially dislike having an argument that's only useful when other args
>   are provided (auth_cache). Not sure how to improve that, though...

What about a py.path.SvnAuth class ... 

* that groks all these options 
* can create the proper commandline switches (and unit-testing
  particularly this) 
* then add an explicit 'svnauth' parameter to wc.checkout and wc.commit
  (which other svnwc methods need it?) 
* add an explicit 'svnauth' param to svnurl methods 
* -- 
* add an explicit 'svnauth' param to the svnurl constructor
  and experiment with inheriting it around

I think that an "SvnAuth" instance should also be 
able to signal "just use defaults/whatever is stored on the FS". 

Eventually we might want to generalize SvnAuth slightly 
into some Identity or Auth class that can also be 
used e.g. for py.execnet.SshGateway.  

HTH, 

holger

-- 
Holger Krekel - freelance manager and programmer 
merlinux GmbH: http://merlinux.de 
py.test: http://pytest.org 
py lib: http://pylib.org 
PyPy: http://codespeak.net/pypy 

From johnny at johnnydebris.net  Tue Feb 12 12:56:16 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Tue, 12 Feb 2008 12:56:16 +0100
Subject: [py-dev] Some ideas
In-Reply-To: <20080212110915.GY17687@solar.trillke>
References: <47B164AC.5040108@johnnydebris.net>
	<20080212110915.GY17687@solar.trillke>
Message-ID: <47B18960.8060902@johnnydebris.net>

holger krekel wrote:
> Transparently inheriting AUTH info might sometimes not be desired
> or be tricky, not sure.  I'd try this after all else is done (see below). 
>
>   
Not sure about this one. If you do a checkout with authentication args, 
all children will be checked out with the same credentials. If you later 
perform an action on that child that requires authentication, I think 
the expected behaviour is that the credentials used for the previous 
checkout are used, unless other credentials are provided.

>> * Many new arguments required
>>
>>   I think it's not very nice to have so many new arguments to the constructors,
>>   and especially dislike having an argument that's only useful when other args
>>   are provided (auth_cache). Not sure how to improve that, though...
>>     
>
> What about a py.path.SvnAuth class ... 
>
>   
I was thinking about something like that, but figured it would be kind 
of heavy for just the SVN auth... However,

> Eventually we might want to generalize SvnAuth slightly 
> into some Identity or Auth class that can also be 
> used e.g. for py.execnet.SshGateway.  
>
>   
in that case it may be nice to have, indeed... ;)

Then...

 > * then add an explicit 'svnauth' parameter to wc.checkout and wc.commit

>  (which other svnwc methods need it?) 

Well, that depends on the use case. For a repository that requires authentication for all types of access, if the path objects aren't created with credentials passed to the constructor, it may be needed for all actions that hit the server (e.g. update, lock, etc.).

Perhaps it makes more sense to only allow passing auth to the constructor? I don't really see a use case for using different credentials for different methods, but I may overlook something?

Cheers,

Guido


From holger at merlinux.de  Tue Feb 12 14:04:19 2008
From: holger at merlinux.de (holger krekel)
Date: Tue, 12 Feb 2008 14:04:19 +0100
Subject: [py-dev] Some ideas
In-Reply-To: <47B18960.8060902@johnnydebris.net>
References: <47B164AC.5040108@johnnydebris.net>
	<20080212110915.GY17687@solar.trillke>
	<47B18960.8060902@johnnydebris.net>
Message-ID: <20080212130418.GZ17687@solar.trillke>

On Tue, Feb 12, 2008 at 12:56 +0100, Guido Wesdorp wrote:
> holger krekel wrote:
> > Transparently inheriting AUTH info might sometimes not be desired
> > or be tricky, not sure.  I'd try this after all else is done (see below). 
> >
> >   
> Not sure about this one. If you do a checkout with authentication args, 
> all children will be checked out with the same credentials. If you later 
> perform an action on that child that requires authentication, I think 
> the expected behaviour is that the credentials used for the previous 
> checkout are used, unless other credentials are provided.

This is what SVN cares for itself by storing credentials in the FS. 
As to in-process (somewhat implicit) inheritance of auth information: 
I hold that it might be complicated to get it right and and simple
enough.  

IMO all methods modifying the repo need to accept
an explicit auth parameter independently if there also 
is auth-inheritance-starting-from-constructor going on or not. 

Due to the many options that an SvnAuth class
needs to handle i'd like to avoid cluttering 
the "parameter namespace" of the svn path constructors. 
The Constructors are anyway already a bit messy IMO. 
Also it's easier for testing to encapsulate things 
in a class and make sure it generates the right 
command line switches etc. when asked for it. 

So what about going ahead with implementing 
this class and using it for the few svnwc methods? 
The SvnAuth class and the issue of inheritance are orthogonal 
issues.  Therefore much testing and work can be done independently. 
I suggest we don't discuss much more currently if that is ok with you.  

holger


> >> * Many new arguments required
> >>
> >>   I think it's not very nice to have so many new arguments to the constructors,
> >>   and especially dislike having an argument that's only useful when other args
> >>   are provided (auth_cache). Not sure how to improve that, though...
> >>     
> >
> > What about a py.path.SvnAuth class ... 
> >
> >   
> I was thinking about something like that, but figured it would be kind 
> of heavy for just the SVN auth... However,

It's more modular and clearer to test IMO (and will be used both
from svnurl's and svnwc's). 
 
> > Eventually we might want to generalize SvnAuth slightly 
> > into some Identity or Auth class that can also be 
> > used e.g. for py.execnet.SshGateway.  
> >
> >   
> in that case it may be nice to have, indeed... ;)

:) 
 
> Then...
> 
>  > * then add an explicit 'svnauth' parameter to wc.checkout and wc.commit
> 
> >  (which other svnwc methods need it?) 
> 
> Well, that depends on the use case. For a repository that requires authentication for all types of access, if the path objects aren't created with credentials passed to the constructor, it may be needed for all actions that hit the server (e.g. update, lock, etc.).

hum, but svnwc does not have that many more (than commit/update/checkout/lock) methods
that actually go the remote repo, does it?  But i haven't checked.  

> Perhaps it makes more sense to only allow passing auth to the constructor? I don't really see a use case for using different credentials for different methods, but I may overlook something?
> 
> Cheers,
> 
> Guido
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
Holger Krekel - freelance manager and programmer 
merlinux GmbH: http://merlinux.de 
py.test: http://pytest.org 
py lib: http://pylib.org 
PyPy: http://codespeak.net/pypy 

From johnny at johnnydebris.net  Wed Feb 13 21:54:22 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Wed, 13 Feb 2008 21:54:22 +0100
Subject: [py-dev] Svn auth update
Message-ID: <47B358FE.8000709@johnnydebris.net>

Hi!

I've implemented the SvnAuth class now, as Holger suggested, and made 
that the svnwc constructor, and the methods that connect to the server, 
all accept it as an argument (and use it, of course ;).

You can see the progress on the 'guido-svn-auth' branch (SvnAuth code in 
py/path/svn/auth.py, and an updated version of the document I attached 
before in py/path/svn/auth.txt).

After playing with the api a bit, I think agree with Holger that passing 
auth to children from methods that return path objects is not necessary, 
and may even be confusing, so perhaps we should indeed skip that for now.

What I do want to add somehow is allow to set the --non-interactive 
switch somehow, although I'm not sure how (it doesn't seem proper to 
have it be part of the authentication information, but having yet 
another argument to all those methods is also not nice).

I guess I'll continue with adding support for the auth argument to 
py.path.svnurl on friday, if no-one objects...

Cheers,

Guido

From holger at merlinux.de  Thu Feb 14 08:56:50 2008
From: holger at merlinux.de (holger krekel)
Date: Thu, 14 Feb 2008 08:56:50 +0100
Subject: [py-dev] Svn auth update
In-Reply-To: <47B358FE.8000709@johnnydebris.net>
References: <47B358FE.8000709@johnnydebris.net>
Message-ID: <20080214075650.GD17687@solar.trillke>

Hi Guido! 

On Wed, Feb 13, 2008 at 21:54 +0100, Guido Wesdorp wrote:
> Hi!
> 
> I've implemented the SvnAuth class now, as Holger suggested, and made 
> that the svnwc constructor, and the methods that connect to the server, 
> all accept it as an argument (and use it, of course ;).

great!  I am still not sure if passing auth to the constructor makes sense, though. 

> You can see the progress on the 'guido-svn-auth' branch (SvnAuth code in 
> py/path/svn/auth.py, and an updated version of the document I attached 
> before in py/path/svn/auth.txt).

I've reviewed and made 51470|1|2 commits accordingly - please check. 
 
> After playing with the api a bit, I think agree with Holger that passing 
> auth to children from methods that return path objects is not necessary, 
> and may even be confusing, so perhaps we should indeed skip that for now.
> 
> What I do want to add somehow is allow to set the --non-interactive 
> switch somehow, although I'm not sure how (it doesn't seem proper to 
> have it be part of the authentication information, but having yet 
> another argument to all those methods is also not nice).

I'd just put it to the SvnAuth class - and modify the docstring 
to say that it encapsulates svn authentication aspects. 

> I guess I'll continue with adding support for the auth argument to 
> py.path.svnurl on friday, if no-one objects...

Could you maybe write a large functional test that creates a 
repo, does checkouts and uses all the wc methods with auth? 

best & cheers, 

holger

From johnny at johnnydebris.net  Thu Feb 14 09:01:38 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Thu, 14 Feb 2008 09:01:38 +0100
Subject: [py-dev] Svn auth update
In-Reply-To: <20080214075650.GD17687@solar.trillke>
References: <47B358FE.8000709@johnnydebris.net>
	<20080214075650.GD17687@solar.trillke>
Message-ID: <47B3F562.9060908@johnnydebris.net>

holger krekel wrote:
> great!  I am still not sure if passing auth to the constructor makes sense, though. 
>
>   
Hm, well, I'm not sure either... It does make the API nicer to use imo, 
though...

> I've reviewed and made 51470|1|2 commits accordingly - please check. 
>   
I checked as the checkin messages came in... :) Looking good, thanks!

> I'd just put it to the SvnAuth class - and modify the docstring 
> to say that it encapsulates svn authentication aspects. 
>
>   
Okay.

> Could you maybe write a large functional test that creates a 
> repo, does checkouts and uses all the wc methods with auth? 
>
>   
Hm, yes, I'll try that...

Thanks for the refactoring and feedback!

Cheers,

Guido

From faassen at startifact.com  Tue Feb 19 20:36:18 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Tue, 19 Feb 2008 20:36:18 +0100
Subject: [py-dev] py.path.svnwc ensure problems
Message-ID: <fpfb3j$5pd$1@ger.gmane.org>

Hi there,

Imagine the following scenario:

* we have a svnwc: wc

* through some external mechanism, a directory 'map5' is created in it.
   This directory is *not* added to SVN using 'svn add' yet.

* now through svnwc, we try to create a file in that directory by using 
.ensure():

   wc.join('map5').join('content').ensure()

We then get the following error:

...
   File 
"/home/faassen/buildout-eggs/py-0.9.0-py2.4.egg/py/path/svn/wccommand.py", 
line 160, in ensure
     p.add()
   File 
"/home/faassen/buildout-eggs/py-0.9.0-py2.4.egg/py/path/svn/wccommand.py", 
line 175, in add
     self._svn('add')
   File 
"/home/faassen/buildout-eggs/py-0.9.0-py2.4.egg/py/path/svn/wccommand.py", 
line 87, in _svn
     out = py.process.cmdexec(string)
   File 
"/home/faassen/buildout-eggs/py-0.9.0-py2.4.egg/py/process/cmdexec.py", 
line 94, in posix_exec_cmd
     ''.join(out), ''.join(err))
Error: ExecutionFailed: 1  LC_ALL=C svn add 
"/home/faassen/tmp/resynch/app2/data/map5/content"
svn: '/home/faassen/tmp/resynch/app2/data/map5' is not a working copy
svn: Can't open file 
'/home/faassen/tmp/resynch/app2/data/map5/.svn/entries': No such file or 
directory

It would be nicer for my purposes if 'ensure()' also ensured that all 
directories above 'content' are added to SVN first (if indeed they 
haven't been added yet).

Would this be good behavior in general for py.path.svnwc, or is there a 
good reason not to do this?

Regards,

Martijn


From faassen at startifact.com  Tue Feb 19 20:49:08 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Tue, 19 Feb 2008 20:49:08 +0100
Subject: [py-dev] py.path.svnwc ensure problems
In-Reply-To: <fpfb3j$5pd$1@ger.gmane.org>
References: <fpfb3j$5pd$1@ger.gmane.org>
Message-ID: <fpfbrl$8fk$1@ger.gmane.org>

Hi there,

Here's an argument why .ensure() should add directories automatically. 
Imagine the following sequence of events:

two checkouts of the same stuff, a and b

In a:

create a directory foo
create a content object bar in foo
svn add foo and bar
svn commit

In b:

svn up
get foo and its contents, bar

Back to a:

svn remove foo
svn commit

Back to b:

change foo/bar
svn up

What happens now is that the foo directory will remain in b, and the
changed 'bar' file will remain as well. Both will however be considered
to be unknown.

One can reproduce this sequence of events working with py.path.svnwc. In 
fact, I have. :) My code has an .ensure() to make sure that foo/bar 
exists. This ensure() fails as 'foo' isn't known to SVN anymore after 
the last SVN up. If ensure() instead re-added 'foo' to SVN, things would 
proceed properly. You would think that ensure() in the case of svnwc 
would need to ensure that the whole path exists in SVN instead of 
bailing out with an error.

One question is what .ensure() should do with any other content in foo 
should foo be automatically added. I guess it should not automatically 
re-add it. Actually in my use case it should actually probably be doing 
so, so I have some thinking to do...

Regards,

Martijn


From holger at merlinux.de  Tue Feb 19 21:51:15 2008
From: holger at merlinux.de (holger krekel)
Date: Tue, 19 Feb 2008 21:51:15 +0100
Subject: [py-dev] py.path.svnwc ensure problems
In-Reply-To: <fpfb3j$5pd$1@ger.gmane.org>
References: <fpfb3j$5pd$1@ger.gmane.org>
Message-ID: <20080219205115.GO17687@solar.trillke>

Hi Martijn! 

On Tue, Feb 19, 2008 at 20:36 +0100, Martijn Faassen wrote:
> 
>    wc.join('map5').join('content').ensure()
>
> We then get the following error:
> 
> ...
> 
> Error: ExecutionFailed: 1  LC_ALL=C svn add 
> "/home/faassen/tmp/resynch/app2/data/map5/content"
> svn: '/home/faassen/tmp/resynch/app2/data/map5' is not a working copy
> svn: Can't open file 
> '/home/faassen/tmp/resynch/app2/data/map5/.svn/entries': No such file or 
> directory
> 
> It would be nicer for my purposes if 'ensure()' also ensured that all 
> directories above 'content' are added to SVN first (if indeed they 
> haven't been added yet).
> Would this be good behavior in general for py.path.svnwc, or is there a 
> good reason not to do this?

I can imagine that this can makes sense.  Might be a bit hairy
to implement, not sure.  In any case I'd rather like to see things 
in terms of tests.  

You might take py/path/svn/testing/test_wccommand.py's
test_ensure as a good starting point for expressing the
desired behaviour.  Feel free to implement it and submit a
patch or just commit to py/trunk if you are sure enough - 
i can review. 

best, 

holger


From johnny at johnnydebris.net  Wed Feb 20 22:43:04 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Wed, 20 Feb 2008 22:43:04 +0100
Subject: [py-dev] svn auth - revisiting svnwc auth object passing
Message-ID: <47BC9EE8.4050706@johnnydebris.net>

Hi there!

I've implemented auth support for py.path.svnurl now too, seems to work 
nicely. Since it requires authentication for just about all its methods, 
I decided (after some discussion with Holger on IRC and some playing 
around) to not have an 'auth' argument to all of the methods. Instead 
only the constructor groks an auth argument, path objects that are 
generated by any of the path's methods 'inherit' it, and an 
'svnurl.auth' property is exposed to allow overriding it. It took a bit 
of playing around to get it to work properly, but I think it does now, 
please take a look if you're interested.

If you like the way this works, I would (again ;) like to ask whether 
I'm allowed to change svnwc so it works the same there - at least, both 
for consistency's sake and because it's a bit cleaner imo - have an auth 
property instead of having the argument to all methods that can connect 
to the server would be nice...

Please let me know what you think.

Cheers,

Guido

From holger at merlinux.de  Sun Feb 24 20:37:06 2008
From: holger at merlinux.de (holger krekel)
Date: Sun, 24 Feb 2008 20:37:06 +0100
Subject: [py-dev] svn auth - revisiting svnwc auth object passing
In-Reply-To: <47BC9EE8.4050706@johnnydebris.net>
References: <47BC9EE8.4050706@johnnydebris.net>
Message-ID: <20080224193706.GN17687@solar.trillke>

Hey Guido, 

some first feedback ... could you refactor the tests such that
e.g. changing the escaping of cmdline commands does not require
lots of changes to test_auth.py?  For example: 

    def test_export(self):
        auth = SvnAuth('foo', 'bar')
        u = svnurl_no_svn('http://foo.bar/svn', auth=auth)
        target = py.path.local('/foo')
        u.export(target)
        assert u.commands[0].endswith('svn export "http://foo.bar/svn" "/foo" '
                                      '--username="foo" --password="bar"')

Apart from that this fails on windows, IMO it would be enough
to test for the presence of the username/password combo
and to do this from one place (and also the creation of "auth"
from place).  IOW: avoid redundancy and nitpicky output checking tests. 

For the slower functional test: could you maybe do some clever
extra setup/teardown and re-use e.g. test_urlcommand.py's 
TestURLCommandPath tests?  Some tests might not work, but then
it's maybe better to rework those.  If adding another base line
for Path APIs i wouldn't like to have to write tests at several
places for it.  IOW: integrate tests some more with existing
tests. 

hope this makes some sense,  I am probably quite busy the
next days. 

best, 

holger




On Wed, Feb 20, 2008 at 22:43 +0100, Guido Wesdorp wrote:
> Hi there!
> 
> I've implemented auth support for py.path.svnurl now too, seems to work 
> nicely. Since it requires authentication for just about all its methods, 
> I decided (after some discussion with Holger on IRC and some playing 
> around) to not have an 'auth' argument to all of the methods. Instead 
> only the constructor groks an auth argument, path objects that are 
> generated by any of the path's methods 'inherit' it, and an 
> 'svnurl.auth' property is exposed to allow overriding it. It took a bit 
> of playing around to get it to work properly, but I think it does now, 
> please take a look if you're interested.
> 
> If you like the way this works, I would (again ;) like to ask whether 
> I'm allowed to change svnwc so it works the same there - at least, both 
> for consistency's sake and because it's a bit cleaner imo - have an auth 
> property instead of having the argument to all methods that can connect 
> to the server would be nice...
> 
> Please let me know what you think.
> 
> Cheers,
> 
> Guido
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
Holger Krekel - freelance manager and programmer 
pylib py.test/greenlets/svn APIs: http://pylib.org 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
merlinux collaborative contracting: http://merlinux.de 

From holger at merlinux.de  Sun Feb 24 20:54:16 2008
From: holger at merlinux.de (holger krekel)
Date: Sun, 24 Feb 2008 20:54:16 +0100
Subject: [py-dev] svn auth - revisiting svnwc auth object passing
In-Reply-To: <20080224193706.GN17687@solar.trillke>
References: <47BC9EE8.4050706@johnnydebris.net>
	<20080224193706.GN17687@solar.trillke>
Message-ID: <20080224195416.GO17687@solar.trillke>

hi again, 

I forgot one thing regarding: please avoid code 
redundancy also with the cache-handling in svnurlcommand 
(and everywhere else for that matter :) as well. E.g. lines such as: 

    auth = self.auth and self.auth.makecmdoptions() or None
    self._lsnorevcache.delentry((self.dirpath().strpath, auth))

appear multiple times.  It's probably best to rather use a helper like

    self._norev_delentry(self.dirpath()) 

and have the helper method figure things out.  Same is true
for the getorbuild where you might introduce a helper maybe as well. 
I haven't checked in detail but maybe it's even possible 
to have the helper disambiguate the cases of "norev" and "rev"
and use caches appropriately.  

Btw, i have the subjective impression that caching
is not working properly - I remember the tests to run much faster. 

thanks & cheers, 
holger

On Sun, Feb 24, 2008 at 20:37 +0100, holger krekel wrote:
> Hey Guido, 
> 
> some first feedback ... could you refactor the tests such that
> e.g. changing the escaping of cmdline commands does not require
> lots of changes to test_auth.py?  For example: 
> 
>     def test_export(self):
>         auth = SvnAuth('foo', 'bar')
>         u = svnurl_no_svn('http://foo.bar/svn', auth=auth)
>         target = py.path.local('/foo')
>         u.export(target)
>         assert u.commands[0].endswith('svn export "http://foo.bar/svn" "/foo" '
>                                       '--username="foo" --password="bar"')
> 
> Apart from that this fails on windows, IMO it would be enough
> to test for the presence of the username/password combo
> and to do this from one place (and also the creation of "auth"
> from place).  IOW: avoid redundancy and nitpicky output checking tests. 
> 
> For the slower functional test: could you maybe do some clever
> extra setup/teardown and re-use e.g. test_urlcommand.py's 
> TestURLCommandPath tests?  Some tests might not work, but then
> it's maybe better to rework those.  If adding another base line
> for Path APIs i wouldn't like to have to write tests at several
> places for it.  IOW: integrate tests some more with existing
> tests. 
> 
> hope this makes some sense,  I am probably quite busy the
> next days. 
> 
> best, 
> 
> holger
> 
> 
> 
> 
> On Wed, Feb 20, 2008 at 22:43 +0100, Guido Wesdorp wrote:
> > Hi there!
> > 
> > I've implemented auth support for py.path.svnurl now too, seems to work 
> > nicely. Since it requires authentication for just about all its methods, 
> > I decided (after some discussion with Holger on IRC and some playing 
> > around) to not have an 'auth' argument to all of the methods. Instead 
> > only the constructor groks an auth argument, path objects that are 
> > generated by any of the path's methods 'inherit' it, and an 
> > 'svnurl.auth' property is exposed to allow overriding it. It took a bit 
> > of playing around to get it to work properly, but I think it does now, 
> > please take a look if you're interested.
> > 
> > If you like the way this works, I would (again ;) like to ask whether 
> > I'm allowed to change svnwc so it works the same there - at least, both 
> > for consistency's sake and because it's a bit cleaner imo - have an auth 
> > property instead of having the argument to all methods that can connect 
> > to the server would be nice...
> > 
> > Please let me know what you think.
> > 
> > Cheers,
> > 
> > Guido
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> > 
> 
> -- 
> Holger Krekel - freelance manager and programmer 
> pylib py.test/greenlets/svn APIs: http://pylib.org 
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
> merlinux collaborative contracting: http://merlinux.de 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
Holger Krekel - freelance manager and programmer 
pylib py.test/greenlets/svn APIs: http://pylib.org 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
merlinux collaborative contracting: http://merlinux.de 

From holger at merlinux.de  Sat Mar  1 10:02:26 2008
From: holger at merlinux.de (Holger Krekel)
Date: Sat, 1 Mar 2008 10:02:26 +0100
Subject: [py-dev] away / dev status
Message-ID: <d235cdc40803010102j22659e1fg5d7cc288d02202f4@mail.gmail.com>

Hello py-dev,

this is note to tell that i am offline at least for march due to
personal troubles.

As to development issues: Guido thankfully agreed to care for a 0.9.1 release
which is to include his svn-auth work and bugfixes since 0.9.0.

Larger changes, much of the current trunk development, and in
particular the event-branch
will probably have to wait. The event branch contains major cleanups
and refactorings.
Here are some notes:

* py/test2 is the directory with the new code.  This is so that you
can use "py.test" to
  test the refactorings.  Otherwise it would not be possible to easily
use py.test to test
  py.test functionality as refactorings would directly affect test
runs themselves.

* config objects now have an event "bus" which has a basic simple (zope3-like)
  subscribe/notify mechanism. See test_bus.py

* ItemTestReports events contain the result of test runs and there is
support for marshalling
  and unmarshalling their contents.  This is the key thing that
allowed to get rid
  of "SerializableOutcome" and duplications of code resulting from the worlds
  of "in-process" and "distrihuted testing".  The idea is that the
to-be-written reporters
  deal with "ItemTestReport" events which already contain formatted
traceback information
  which is generated directly at the time a failure occurs (previously
such information
  was extracted much later when the failure reports were actually
printed at the end of a test run)

* main TODO item is the re-instantiation and re-viving of the Text-
and other reporters
  which need to be adapated to the new event mechanisms.  It should
also be possible
  to have e.g. a Webreporter and a Testreporter and a new
"File-reporter"co-exist because
  they all just subscribe to CollectionStart/Finish and ItemTestReports.

* If you work on the branch i'd suggest to first read the files of the
current py/test2.
  I am saying this because the previous code contained a lot of
painful duplication
  and it'd be good to avoid this happening again.

anyway, wish you all a good time,
take care,

holger

From holger at merlinux.de  Sat Mar  1 10:05:04 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 1 Mar 2008 10:05:04 +0100
Subject: [py-dev] away / dev status [reformatted]
In-Reply-To: <d235cdc40803010102j22659e1fg5d7cc288d02202f4@mail.gmail.com>
References: <d235cdc40803010102j22659e1fg5d7cc288d02202f4@mail.gmail.com>
Message-ID: <20080301090504.GS17687@solar.trillke>

(same mail, but properly formatted)

Hello py-dev,

this is note to tell that i am offline at least for march due to
personal troubles.

As to development issues: Guido thankfully agreed to care for
a 0.9.1 release which is to include his svn-auth work and
bugfixes since 0.9.0.

Larger changes, much of the current trunk development, and in
particular the event-branch will probably have to wait. The
event branch contains major cleanups and refactorings.  Here
are some notes:

* py/test2 is the directory with the new code.  This is so
  that you can use "py.test" to test the refactorings.  Otherwise it
  would not be possible to easily use py.test to test py.test
  functionality as refactorings would directly affect test runs
  themselves.

* config objects now have an event "bus" which has a basic simple (zope3-like)
  subscribe/notify mechanism. See test_bus.py

* ItemTestReports events contain the result of test runs and
  there is support for marshalling and unmarshalling their contents.
  This is the key thing that allowed to get rid of
  "SerializableOutcome" and duplications of code resulting from
  the worlds of "in-process" and "distrihuted testing".  The
  idea is that the to-be-written reporters deal with
  "ItemTestReport" events which already contain formatted
  traceback information which is generated directly at the time
  a failure occurs (previously such information was extracted
  much later when the failure reports were actually printed at
  the end of a test run)

* main TODO item is the re-instantiation and re-viving of the
  Text-and other reporters which need to be adapated to the new event
  mechanisms.  It should also be possible to have e.g. a
  Webreporter and a Testreporter and a new "File-reporter" 
  co-exist because they all just subscribe to CollectionStart/Finish 
  and ItemTestReports.

* If you work on the branch i'd suggest to first read the
  files of the current py/test2.  I am saying this because the previous code
  contained a lot of painful duplication and it'd be good to
  avoid this happening again.

anyway, wish you all a good time,
take care,

holger
_______________________________________________
py-dev mailing list
py-dev at codespeak.net
http://codespeak.net/mailman/listinfo/py-dev


From johnny at johnnydebris.net  Tue Mar 11 11:09:06 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Tue, 11 Mar 2008 11:09:06 +0100
Subject: [py-dev] 0.9.1 progress
Message-ID: <47D65A42.1020105@johnnydebris.net>

Hello!

Since I'm rather busy, progress on the py lib release has been slow, but 
not entirely fruitless: I wrote a script that grabs the 0.9 branch and a 
list of revisions, then gets a diff from the trunk for each of those 
revisions, extracts patches from the diffs and applies them 
incrementally (updating the branch on each revision). Then, for each 
revision, after the patches are applied, the tests are run.

This script seems to work nicely, I've played around a bit and if I only 
apply the bugfix releases I end up with a fully working working copy 
(iow: all tests pass after application of the last patch). When I also 
do all small features (simple changes that required one or two checkins 
directly on the trunk), I have one single exception somewhere in 
py.test, can't remember the exact details but it seemed easy enough to 
fix. When I also apply all merges (so larger features that were 
developed on a branch and merged to the trunk) I get a failure on the 
'less threads for execnet' feature (merged in rev. 45539), I didn't 
investigate in detail yet, as I think merging this is out of scope for 
0.9.1 anyway.

So here comes my question: do you guys agree to just apply the bugfix 
revisions (see one of my previous mails on py-dev for the exact list - 
it's the 'bugfixes/refactorings' part)? And if not, which revisions do 
you want to have in 0.9.1 besides the ones mentioned in the list?

I'll be spending tomorrow (wednesday) on applying the bugfixes, and will 
check the results in on a branch. If all goes well, the branch should be 
ready for release (although some testing first would be nice, of course 
:) tomorrow evening.

Cheers,

Guido

From brian at dorseys.org  Tue Mar 11 18:31:06 2008
From: brian at dorseys.org (Brian Dorsey)
Date: Tue, 11 Mar 2008 10:31:06 -0700
Subject: [py-dev] 0.9.1 progress
In-Reply-To: <47D65A42.1020105@johnnydebris.net>
References: <47D65A42.1020105@johnnydebris.net>
Message-ID: <66e877b70803111031s1231cc2ev7278b8e8c04620e1@mail.gmail.com>

On Tue, Mar 11, 2008 at 3:09 AM, Guido Wesdorp <johnny at johnnydebris.net> wrote:
>  So here comes my question: do you guys agree to just apply the bugfix
>  revisions?

Sounds great to me. I can give it a quick test on Windows once you're finished.

Take care,
  -Brian

From johnny at johnnydebris.net  Tue Mar 11 22:33:08 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Tue, 11 Mar 2008 22:33:08 +0100
Subject: [py-dev] 0.9.1 progress
In-Reply-To: <66e877b70803111031s1231cc2ev7278b8e8c04620e1@mail.gmail.com>
References: <47D65A42.1020105@johnnydebris.net>
	<66e877b70803111031s1231cc2ev7278b8e8c04620e1@mail.gmail.com>
Message-ID: <47D6FA94.4050502@johnnydebris.net>

Brian Dorsey wrote:
> Sounds great to me. I can give it a quick test on Windows once you're finished.
>
>   
That would be very useful. I'll try to have something available  for 
testing tomorrow evening.

Cheers,

Guido

From ebenze at hotmail.com  Sun Mar 16 14:53:03 2008
From: ebenze at hotmail.com (Eric B.)
Date: Sun, 16 Mar 2008 09:53:03 -0400
Subject: [py-dev] Cannot build Python 2.4 SRPM on x64 platform
Message-ID: <frj96e$jlm$1@ger.gmane.org>

Hi,

For those on several python lists, I appologize in advance for
cross-posting, but I'm really not sure which list is best to ask for
assistance with this.

Currently, I am trying to build the python2.4 SRPM from Python.org on a
RHEL4 x64 platform, but the build is failing with a very non-descript
error message.

....
+ cd /var/tmp/python2.4-2.4-root/usr/bin
+ mv -f pydoc pydoc2.4
+ cd /var/tmp/python2.4-2.4-root/usr/bin
+ mv -f idle idle2.4
+ echo '#!/bin/bash'
+ echo 'exec /usr/bin/python2.4 /usr/lib64/python2.4/idlelib/idle.py'
+ chmod 755 /var/tmp/python2.4-2.4-root/usr/bin/idle2.4
+ cp -a Tools /var/tmp/python2.4-2.4-root/usr/lib64/python2.4
+ rm -f mainpkg.files
+ find /var/tmp/python2.4-2.4-root/usr/lib64/python2.4/lib-dynload -type f
+ sed 's|^/var/tmp/python2.4-2.4-root|/|'
+ grep -v -e '_tkinter.so$'
error: Bad exit status from /var/tmp/rpm-tmp.55639 (%install)


RPM build errors:
    user jafo does not exist - using root
    group jafo does not exist - using root
    user jafo does not exist - using root
    group jafo does not exist - using root
    Bad exit status from /var/tmp/rpm-tmp.55639 (%install)


If I try to run /var/tmp/rpm-tmp.55639 manually from the prompt manually
after the rpmbuild fails, it runs properly to completion.  If I try to
comment out that last line (find
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/lib-dynload -type f | sed
's|^/var/tmp/python2.4-2.4-root|/|' | grep -v -e '_tkinter.so$' ) that seems
to be causing the script to fail, rpmbuild finishes, but with several error
msgs, complaining about missing files in the lib64 directories:

+ rm -f /tmp/python-rpm-files.4859
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip
+ /usr/lib/rpm/brp-strip-static-archive
+ /usr/lib/rpm/brp-strip-comment-note
Processing files: python2.4-2.4-1pydotorg
error: File not found by glob:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/*.txt
error: File not found by glob:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/*.py*
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/pdb.doc
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/profile.doc
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/curses
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/distutils
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/encodings
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/plat-linux2
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/site-packages
error: File not found: /var/tmp/python2.4-2.4-root/usr/lib64/python2.4/test
error: File not found: /var/tmp/python2.4-2.4-root/usr/lib64/python2.4/xml
error: File not found: /var/tmp/python2.4-2.4-root/usr/lib64/python2.4/email
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/compiler
error: File not found: /var/tmp/python2.4-2.4-root/usr/lib64/python2.4/bsddb
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/hotshot
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/logging
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/lib-old
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.95118
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd Python-2.4
+ DOCDIR=/var/tmp/python2.4-2.4-root/usr/share/doc/python2.4-2.4
+ export DOCDIR
+ rm -rf /var/tmp/python2.4-2.4-root/usr/share/doc/python2.4-2.4
+ /bin/mkdir -p /var/tmp/python2.4-2.4-root/usr/share/doc/python2.4-2.4
+ cp -pr Misc/README Misc/cheatsheet Misc/Porting
/var/tmp/python2.4-2.4-root/usr/share/doc/python2.4-2.4
+ cp -pr LICENSE Misc/ACKS Misc/HISTORY Misc/NEWS
/var/tmp/python2.4-2.4-root/usr/share/doc/python2.4-2.4
+ exit 0
Processing files: python2.4-devel-2.4-1pydotorg
error: File not found:
/var/tmp/python2.4-2.4-root/usr/lib64/python2.4/config
Processing files: python2.4-tools-2.4-1pydotorg
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <=
3.0.3-1
Requires: /bin/bash /bin/sh /usr/bin/env


Finally, if I try searching for any files in the
usr/lib64/python2.4/lib-dynload  or usr/lib64/python2.4/idlelib directories
manually, I don't see any files at all in those directories.


To me, it seems as though python is either not installing the files in the
right places, or the script is searching for files in the wrong places, but
I'm completely guessing here.

Has anyone managed to build Python2.4 on a RHEL4 x64 system?  Can anyone
point me in the right direction to complete this build successfully?  I'm
hoping to get the binaries built so I can contribute them to the python.org
site so others don't need to go through these problems in the future.

Any hints / ideas / suggestions / guidance that anyone can provide would
amazing, because I'm completely out of ideas at this point.  Like I said, 
I'm trying to build this on a RHEL4 x64 system, with all latest updates.

Thanks so much!

Eric





From johnny at johnnydebris.net  Mon Mar 17 20:21:06 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Mon, 17 Mar 2008 20:21:06 +0100
Subject: [py-dev] Merged changes back into the trunk, please test...
Message-ID: <47DEC4A2.2090705@johnnydebris.net>

Hi!

After some more delays, I've now applied a set of trunk changes to the 
0.9.0-bugfix branch that seems to result in a relatively stable 
situation, hopefully good enough for 0.9.1. Please, if you have some 
time, check out the branch, run the tests and let me know what you think...

Branch URL: https://codespeak.net/svn/py/branch/bugfix-0.9.0

Thanks in advance!

Cheers,

Guido

From brian at dorseys.org  Mon Mar 17 21:44:34 2008
From: brian at dorseys.org (Brian Dorsey)
Date: Mon, 17 Mar 2008 13:44:34 -0700
Subject: [py-dev] Merged changes back into the trunk, please test...
In-Reply-To: <47DEC4A2.2090705@johnnydebris.net>
References: <47DEC4A2.2090705@johnnydebris.net>
Message-ID: <66e877b70803171344pe8da2f9u3a2b8621a6eefa2@mail.gmail.com>

On Mon, Mar 17, 2008 at 12:21 PM, Guido Wesdorp <johnny at johnnydebris.net> wrote:
>  Please, if you have some
>  time, check out the branch, run the tests and let me know what you think...

I just checked in one small spelling fix, and after that I get:

========== tests finished: 1238 passed, 171 skipped in 75.93 seconds ==========

This is on Windows Vista with Python 2.5.2.

Looking good!

(actually better than trunk on my machine, where I can't actually make
it through a full run of the tests successfully today. Mostly due to
greenlet tests which should be disabled on my machine)

Take care,
  -Brian

From stephan.diehl at gmx.net  Tue Mar 18 11:38:56 2008
From: stephan.diehl at gmx.net (Stephan Diehl)
Date: Tue, 18 Mar 2008 11:38:56 +0100
Subject: [py-dev] problem with py.test --exec switch
Message-ID: <200803181138.56949.stephan.diehl@gmx.net>

Hi,

problem: I want to run pypy/lib/app_test/test_stackless.py.
It runs fine, if I just do a
py.test test_stackless.py 
(this runs the stackless tests on top of CPython with the help of greenlets)
But if I try to use another python interpreter with, for example (stackless is 
my stackless interpreter; could be pypy-c instead, whatever really):
py.test --exec=stackless test_stackless.py
It hangs in the 'test_send_counter'.
This really seems to be a problem with the '--exec', because if I do a
stackless /my/path/to/py.test test_stackless.py
I see no problems.
Are there any obvious entry points to look at? (py.test does has it's 'magic' 
moments)

Thanks

Stephan

From johnny at johnnydebris.net  Fri Mar 21 18:48:07 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Fri, 21 Mar 2008 18:48:07 +0100
Subject: [py-dev] Building the C extensions on Windows
Message-ID: <47E3F4D7.7080007@johnnydebris.net>

Hi!

I was wondering if anyone knows how to build the C extensions on 
Windows. I would like to get a release out of the door and I'm not sure 
how to do the Windows part...

Cheers,

Guido

From Jim.Vickroy at noaa.gov  Thu Mar 27 15:38:17 2008
From: Jim.Vickroy at noaa.gov (Jim Vickroy)
Date: Thu, 27 Mar 2008 08:38:17 -0600
Subject: [py-dev] unittest docstring behavior in py.test?
Message-ID: <47EBB159.6090707@noaa.gov>

Hello all,

I'm a recent convert to py.test (from unittest).  I like py.test, and 
wish to thanks its developers.

One feature I like about unittest is its ability to optionally echo each 
test docstring (if provided) as it runs.  I used this feature to make a 
simple statement about a behavior of the component being tested.  This 
proved useful for requirements validation since at the conclusion of a 
test run, I had a set of statements about the behaviors of the 
components being tested.  Is there some comparable capability with 
py.test?  If not, is there some alternate approach to achieve this 
(namely, a set of statements about the behaviors of tested components)?

Thanks for your feedback.

-- jv

From johnny at johnnydebris.net  Sun Mar 30 10:25:48 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Sun, 30 Mar 2008 10:25:48 +0200
Subject: [py-dev] Py lib 0.9.1 released
Message-ID: <47EF4E8C.1080803@johnnydebris.net>

py lib 0.9.1: bugfix release
=============================

The py lib team has just released version 0.9.1 of the py lib - a 
library aiming to support agile and test-driven python development on 
various levels.

This is mostly a bugfix release, with a couple of new features sneaked in.
Most important changes:

* reduced the number of threads used in py.execnet
* some new functionality (authentication, export, locking) in py.path's
  Subversion APIs
* stability and segfault fixes in execnet
* numerous small fixes in py.test's rsession (experimental pluggable 
session)
  and generative test features
* some fixes in the py.test core
* added py.misc.killproc, which allows killing processes on (some 
flavours of) Windows and UNIX

For a complete list of changes, see doc/changes-0.9.1.txt in the source 
package.

Download/Install:   http://codespeak.net/py/0.9.1/download.html
Documentation/API:  http://codespeak.net/py/0.9.1/index.html

Work on the py lib has been partially funded by the European Union IST 
programme and by http://merlinux.de within the PyPy project.

best, have fun and let us know what you think!

holger krekel, Maciej Fijalkowski,
Carl Friedrich Bolz, Guido Wesdorp