From holger at merlinux.de  Thu Jul  3 12:02:08 2008
From: holger at merlinux.de (holger krekel)
Date: Thu, 3 Jul 2008 12:02:08 +0200
Subject: [py-dev] py.test bug: large stack trace produced with
	full	source dump on import failure
In-Reply-To: <B139642B478B4202A352C04FD39D211D@gigabytex48dq>
References: <B139642B478B4202A352C04FD39D211D@gigabytex48dq>
Message-ID: <20080703100208.GY759@trillke.net>

Hi Baptiste,

On Fri, Jun 27, 2008 at 10:45 +0200, Baptiste Lepilleur wrote:
> I have run into an issue with py.test which make it pretty much unsable with 
> the following scenario:
> - a test module import another module
> - the import fails due to an exception thrown by the other module
> 
> This scenario raise two bugs (hopefully this is the scenario to reproduce 
> this bug):
> - Py.test produces a stack trace with a full source dump of the imported 
> module source
> - Information about the exception that caused the failure is missing.
> 
> The source does not end line 2269, so my guess is that py.test dump the 
> source until the source line where the exception was raised.

exactly. 

> I believe py.test should truncate the source to show only the relevant part, 
> that is ignore the 2000 lines until the global variable declaration 
> SCHEMA_SCHEMA in this case.

Hum, in other cases it might be interesting to see the context, though. 
E.g. if you have a couple of global statements where the
failing one depends on values produced by earlier ones. 

I am not sure what the exact rule should be for such contexts 
but your example showcases that we should try to improve,
indeed.  

thanks & best, 

holger

> To illustrate the issue, I've put excerpt from both the standard python 
> stacktrace and the py.test failure below:
> 
> *** Standard python traces:
> **********************
> ---
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] 
> on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import test_sbuildformat
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File 
> "E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\testing\test_sbuildformat.py", 
> line 4, in <module>
>     import sbuilder.sbuildfileformat as sbuildfileformat
>   File 
> "E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\sbuildfileformat.py", 
> line 2507, in <module>
>     SCHEMA_SCHEMA = getSchemaSchema()
>   File 
> "E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\sbuildfileformat.py", 
> line 2269, in getSchemaSchema
>     error_log.makeErrorReport( tokenizer.getNormalizedInput(), 13 )
> sbuilder.sbuildfileformat.SchemaTypeParameterError
> >>>
> ---
> 
> **** Py.test traces (abrievated, full source dump is 120KO)
> **********************************************
> ============================= test process starts 
> =============================
> executable:   c:\Python25\python.exe  (2.5.2-final-0)
> using py lib: c:\Python25\lib\site-packages\py <rev unknown>
> 
> test_sbuilder.py[1] .
> test_sbuildformat.py - FAILED TO LOAD MODULE
> 
> _______________________________________________________________________________
> ________________________________ entrypoint: 
> _________________________________
> 
>     from __future__ import generators
>     import types
>     import re
> >   import sbuilder.sbuildfileformat as sbuildfileformat
> 
> [E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\testing\test_sbuildformat.py:4]
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ _
> 
>     import types
>     import sets
>     import weakref
> 
> [....] 120KO later:
> 
> >   SCHEMA_SCHEMA = getSchemaSchema()
> 
> [E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\sbuildfileformat.py:2507]
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ _
> 
>     def getSchemaSchema():
>         """Returns a document representing a schema of a schema.
>         This can be used to validate a schema.
>         Exceptions:
>         - DocumentParsingError if failed to parse the schema text document
>           (should never occurs, it is a bug introduced when updating the 
> schema).
>         -
>         """
>         error_log = ErrorLog( synchronous_display = False )
>         error_memo = error_log.errorMemo()
>         tokenizer = Tokenizer( getSchemaTextDocument(), 'schema.schema', 
> error_log )
>         parser = Parser( tokenizer, error_log )
>         schema_value = parser.parse()
>         if schema_value is None:
>             raise DocumentParsingError, \
>                   error_log.makeErrorReport( tokenizer.getNormalizedInput(), 
> 13 )
> 
>         try:
>             schema_schema = SchemaBuilder(error_log).getSchema( 
> schema_value )
>             if schema_schema and not schema_schema.check( error_log ):
>                 schema_schema = None
>         except SchemaTypeParameterError, error:
>             error.log( error_log )
>             schema_schema = None
>         if schema_schema is None or error_log.hasNewErrorsSinceMemo( 
> error_memo ):
>             raise SchemaTypeParameterError, \
> E                 error_log.makeErrorReport( tokenizer.getNormalizedInput(), 
> 13 )
> >                 SchemaTypeParameterError
> 
> [E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\sbuildfileformat.py:2269]
> _______________________________________________________________________________
> ============= tests finished: 1 passed, 1 failed in 0.09 seconds 
> ==============
> 
> Regards,
> Baptiste.
> 
> _______________________________________________
> 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.eu 

From holger at merlinux.de  Fri Jul  4 08:50:51 2008
From: holger at merlinux.de (holger krekel)
Date: Fri, 4 Jul 2008 08:50:51 +0200
Subject: [py-dev] broken/notimplemented?
Message-ID: <20080704065051.GN759@trillke.net>

Hi Guido, (and maciej?) 

in the 0.9.1 release i see that "py.test.broken" and
"py.test.notimplemented" were introduced into the namespace.
What is the rationale?  

they don't have docstrings for one and they seem to be
redundant, i.e. just be versions of skip.  In r59284 
i removed them for now and adjusted the test to 
show how you can get the same effect with skip. 
Also doesn't seem to me like it's used anywhere. 

holger

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

From johnny at johnnydebris.net  Fri Jul  4 16:22:54 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Fri, 04 Jul 2008 16:22:54 +0200
Subject: [py-dev] broken/notimplemented?
In-Reply-To: <20080704065051.GN759@trillke.net>
References: <20080704065051.GN759@trillke.net>
Message-ID: <486E323E.6060500@johnnydebris.net>

holger krekel wrote:
> in the 0.9.1 release i see that "py.test.broken" and
> "py.test.notimplemented" were introduced into the namespace.
> What is the rationale?  
>
>   
Hm, doesn't ring a bell, I probably have merged them in because there 
seemed to be a dependency on them from other bits of code, or because 
the checkin was part of other changes, or even because the checkin 
message for the change was confusing... Anyway, not sure if they can 
just go, I guess it's best to ask Maciek.

Cheers,

Guido


From holger at merlinux.de  Sat Jul  5 08:36:47 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 5 Jul 2008 08:36:47 +0200
Subject: [py-dev] ep2008 talk draft
Message-ID: <20080705063647.GX759@trillke.net>

Hi all, 

at http://codespeak.net/svn/py/extradoc/talk/ep2008 
you can checkout my talk draft for the 1h beginner level
tutorial at EuroPython 2008 in Vilnius.  Look at pytest.html 
or maybe go through pytest.txt.  Happy about any reviews and 
feedback, including commits.  Special thanks to Guido, Armin, CF 
for contributions of their conftests. 

best, 

holger

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

From blep at users.sourceforge.net  Sat Jul  5 09:32:29 2008
From: blep at users.sourceforge.net (Baptiste Lepilleur)
Date: Sat, 5 Jul 2008 09:32:29 +0200
Subject: [py-dev] py.test bug: large stack trace produced with
	fullsource dump on import failure
References: <B139642B478B4202A352C04FD39D211D@gigabytex48dq>
	<20080703100208.GY759@trillke.net>
Message-ID: <EB08428982D3465B97C1B9D13A1183CE@gigabytex48dq>

----- Original Message ----- 
From: "holger krekel" <holger at merlinux.de>
To: "Baptiste Lepilleur" <blep at users.sourceforge.net>
Cc: <py-dev at codespeak.net>
Sent: Thursday, July 03, 2008 12:02 PM
Subject: Re: [py-dev] py.test bug: large stack trace produced with 
fullsource dump on import failure


> Hi Baptiste,
>
> On Fri, Jun 27, 2008 at 10:45 +0200, Baptiste Lepilleur wrote:
>> I have run into an issue with py.test which make it pretty much unsable 
>> with
>> the following scenario:
>> - a test module import another module
>> - the import fails due to an exception thrown by the other module
>>
>> This scenario raise two bugs (hopefully this is the scenario to reproduce
>> this bug):
>> - Py.test produces a stack trace with a full source dump of the imported
>> module source
>> - Information about the exception that caused the failure is missing.
>>
>> The source does not end line 2269, so my guess is that py.test dump the
>> source until the source line where the exception was raised.
>
> exactly.
>
>> I believe py.test should truncate the source to show only the relevant 
>> part,
>> that is ignore the 2000 lines until the global variable declaration
>> SCHEMA_SCHEMA in this case.
>
> Hum, in other cases it might be interesting to see the context, though.
> E.g. if you have a couple of global statements where the
> failing one depends on values produced by earlier ones.
>
I did not know this feature was present, though I've never seen it 
triggering. Does it works with module level global variable ?

> I am not sure what the exact rule should be for such contexts
> but your example showcases that we should try to improve,
> indeed.

My rules of the thumb would be something like:
If the trace at a given level of the stack is longer than two screen in 
height, then truncates it and show only the relevant part. Otherwise, the 
developper will likely spent more time analysing the trace than fixing the 
test.
How frequent is the use case you quote above ? I never stumbled on such a 
case, though I don't write that much python code...

>
> thanks & best,
>
> holger
---
Baptiste Lepilleur <blep at users.sourceforge.net>


From blep at users.sourceforge.net  Sat Jul  5 10:03:03 2008
From: blep at users.sourceforge.net (Baptiste Lepilleur)
Date: Sat, 5 Jul 2008 10:03:03 +0200
Subject: [py-dev] py.test --looponfailing started failing on Windows...
Message-ID: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>

I'm stuck with this weird issue. py.test -f has worked perfectly for more than one month, but yesterday I got my first failure as shown below. The weird thing is that it restarted worked fine after failing a few times, but this morning it is impossible to get it working...

Environment: Python 2.5.2 on Windows XP SP3 32 bits and py-0.9.1 install via setup.py.

Below are the failure output when I start py.test -f, and the debug ouput of the gateway trace that I enabled. Anyone know how to get useful information about the remote exception (like source code... to help understand where this ValueError come from ?)

I tried to run the gateway unit test, but they always get stuck. The strange thing is that it seems to be depend on how they are started with py.test: 
If I starts the test with disabled stdout capture (py.test -v -s) , then the test remain stuck on:
 test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py,
If I starts the test normally (py.test -v), then test run go farther but get stuck on:
test_gateway.py:405  TestPopenGateway().test_chdir_separation
Gateway debug trace for unit test do not show any ValueError exception...
Unit tests output is at the end of the mail.

Any help to understand where I should add traces in the code to understand what is going on would be greatly appreciated.

Thanks,
Baptiste.

* The failure:
E:\prg\py\App\sbuilder\build\src\sbuilder\testing>py.test.py  -f
* opening PopenGateway:  C:\Python25\python.exe
MASTER: initiated slave terminal session ->
MASTER: send start info, topdir=E:\prg\py\App\sbuilder\build\src
Traceback (most recent call last):
  File "E:\prg\py\App\sbuilder\build\src\sbuilder\testing\py.test.py", line 4, in <module>
    py.test.cmdline.main()
  File "c:\Python25\lib\site-packages\py\test\cmdline.py", line 15, in main
    failures = session.main()
  File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 82, in main
    failures = self.run_remote_session(failures)
  File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 111, in run_remote_session
    return channel.receive()
  File "C:\Python25\lib\site-packages\py\execnet\channel.py", line 175, in receive
    raise self._getremoteerror() or EOFError()
EOFError

I enabled the gateway trace I found:
**** execnet-debug-3420:
sending gateway bootstrap code
Channel(3).__del__
sent -> <Message.CHANNEL_LAST_MESSAGE channelid=3 ''>
Channel(5).__del__
sent -> <Message.CHANNEL_LAST_MESSAGE channelid=5 ''>
sent -> <Message.CHANNEL_OPEN channelid=1 len=111>
sent -> <Message.CHANNEL_DATA channelid=1 len=456>
leaving <Thread(receiver, started daemon)>
====================cleaning up====================
Channel(1).__del__


*** execnet-debug-2308 
Traceback (most recent call last):
  File "<string>", line 359, in _thread_receiver
  File "<string>", line 626, in readfrom
ValueError: bad data format

leaving <Thread(receiver, started daemon)>
_servemain finished
====================cleaning up====================


*** Results of running the unit tests for exec_net module
C:\Python25\Lib\site-packages\py\execnet\testing>python c:\Python25\Lib\site-packages\py\bin\py.test -v
inserting into sys.path: C:\Python25\Lib\site-packages
============================= test process starts =============================
executable:   c:\Python25\python.exe  (2.5.2-final-0)
using py lib: C:\Python25\Lib\site-packages\py <rev unknown>
test target:  C:\Python25\Lib\site-packages\py\execnet\testing
initial conf 0: C:\Python25\Lib\site-packages\py\test\defaultconftest.pyc
initial conf 1: C:\Python25\Lib\site-packages\py\conftest.pyc


+ testmodule: C:\Python25\Lib\site-packages\py\execnet\testing\test_gateway.py
register.py:20       test_getsource_import_modules[0] ok (0.00)
register.py:20       test_getsource_import_modules[1] ok (0.00)
register.py:20       test_getsource_import_modules[2] ok (0.00)
register.py:20       test_getsource_import_modules[3] ok (0.00)
register.py:20       test_getsource_import_modules[4] ok (0.00)
test_gateway.py:17   test_getsource_no_colision ok (0.00)
test_gateway.py:30   test_stdouterrin_setnull ok (0.02)
test_gateway.py:45   TestMessage().test_wire_protocol ok (0.00)
test_gateway.py:61   TestPureChannel().test_factory_create ok (0.00)
test_gateway.py:67   TestPureChannel().test_factory_getitem ok (0.00)
test_gateway.py:73   TestPureChannel().test_channel_timeouterror ok (0.02)
test_gateway.py:85   TestPopenGateway().test_correct_setup ok (0.08)
test_gateway.py:88   TestPopenGateway().test_repr_doesnt_crash ok (0.00)
test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py ok (0.02)
test_gateway.py:100  TestPopenGateway().test_remote_exec_waitclose ok (0.00)
test_gateway.py:104  TestPopenGateway().test_remote_exec_waitclose_2 ok (0.00)
test_gateway.py:108  TestPopenGateway().test_remote_exec_waitclose_noarg ok (0.00)
test_gateway.py:112  TestPopenGateway().test_remote_exec_error_after_close ok (0.00)
test_gateway.py:117  TestPopenGateway().test_remote_exec_channel_anonymous ok (0.00)
test_gateway.py:126  TestPopenGateway().test_channel_close_and_then_receive_error ok (0.00)
test_gateway.py:130  TestPopenGateway().test_channel_finish_and_then_EOFError ok (0.00)
test_gateway.py:138  TestPopenGateway().test_channel_close_and_then_receive_error_multiple ok (0.00)

test_gateway.py:144  TestPopenGateway().test_channel__local_close ok (0.00)
test_gateway.py:149  TestPopenGateway().test_channel__local_close_error ok (0.00)
test_gateway.py:155  TestPopenGateway().test_channel_error_reporting ok (0.00)
test_gateway.py:166  TestPopenGateway().test_channel_syntax_error ok (0.00)
test_gateway.py:175  TestPopenGateway().test_channel_iter ok (0.00)
test_gateway.py:183  TestPopenGateway().test_channel_passing_over_channel ok (0.00)
test_gateway.py:202  TestPopenGateway().test_channel_receiver_callback ok (0.00)
test_gateway.py:217  TestPopenGateway().test_channel_callback_after_receive ok (0.02)
test_gateway.py:233  TestPopenGateway().test_waiting_for_callbacks ok (0.22)
test_gateway.py:245  TestPopenGateway().test_channel_callback_stays_active ok (0.75)
test_gateway.py:275  TestPopenGateway().test_channel_callback_remote_freed ok (0.75)
test_gateway.py:279  TestPopenGateway().test_channel_endmarker_callback ok (0.00)
test_gateway.py:294  TestPopenGateway().test_remote_redirect_stdout ok (0.00)
test_gateway.py:303  TestPopenGateway().test_remote_exec_redirect_multi ok (0.00)
test_gateway.py:318  TestPopenGateway().test_channel_file ok (0.00)
test_gateway.py:330  TestPopenGateway().test_channel_file_write_error ok (0.00)
test_gateway.py:336  TestPopenGateway().test_channel_file_proxyclose ok (0.02)
test_gateway.py:347  TestPopenGateway().test_confusion_from_os_write_stdout ok (0.00)
test_gateway.py:361  TestPopenGateway().test_confusion_from_os_write_stderr ok (0.00)
test_gateway.py:375  TestPopenGateway().test_non_reverse_execution ok (0.03)
test_gateway.py:405  TestPopenGateway().test_chdir_separation ^C
C:\Python25\Lib\site-packages\py\execnet\testing>

---
Baptiste Lepilleur <blep at users.sourceforge.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20080705/e56f5b2a/attachment-0001.htm 

From holger at merlinux.de  Sat Jul  5 10:31:18 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 5 Jul 2008 10:31:18 +0200
Subject: [py-dev] py.test --looponfailing started failing on Windows...
In-Reply-To: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>
References: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>
Message-ID: <20080705083118.GZ759@trillke.net>

Hi Baptiste, 

thanks for your good report.  Debugging such issues is often 
tedious.  but let's try.  I assume that you have no changes 
to the system or the python version that you are aware of. 

Before doing anything more, please do a "py/bin/py.cleanup"
on your complete project - this erases all .pyc files. 
and check if the problem goes away. 

then ... 

On Sat, Jul 05, 2008 at 10:03 +0200, Baptiste Lepilleur wrote:
>   File "E:\prg\py\App\sbuilder\build\src\sbuilder\testing\py.test.py", line 4, in <module>
>     py.test.cmdline.main()
>   File "c:\Python25\lib\site-packages\py\test\cmdline.py", line 15, in main
>     failures = session.main()
>   File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 82, in main
>     failures = self.run_remote_session(failures)
>   File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 111, in run_remote_session
>     return channel.receive()
>   File "C:\Python25\lib\site-packages\py\execnet\channel.py", line 175, in receive
>     raise self._getremoteerror() or EOFError()
> EOFError
> 
> I enabled the gateway trace I found:
> **** execnet-debug-3420:
> sending gateway bootstrap code
> Channel(3).__del__
> sent -> <Message.CHANNEL_LAST_MESSAGE channelid=3 ''>
> Channel(5).__del__
> sent -> <Message.CHANNEL_LAST_MESSAGE channelid=5 ''>
> sent -> <Message.CHANNEL_OPEN channelid=1 len=111>
> sent -> <Message.CHANNEL_DATA channelid=1 len=456>
> leaving <Thread(receiver, started daemon)>
> ====================cleaning up====================
> Channel(1).__del__
> 
> 
> *** execnet-debug-2308 
> Traceback (most recent call last):
>   File "<string>", line 359, in _thread_receiver
>   File "<string>", line 626, in readfrom
> ValueError: bad data format


Can you go to py/execnet/message.py:43 and add some more info
to the exception string and report back what you get? 

best,

holger 

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

From holger at merlinux.de  Sat Jul  5 10:37:48 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 5 Jul 2008 10:37:48 +0200
Subject: [py-dev] truncate too long tracebacks
In-Reply-To: <EB08428982D3465B97C1B9D13A1183CE@gigabytex48dq>
References: <B139642B478B4202A352C04FD39D211D@gigabytex48dq>
	<20080703100208.GY759@trillke.net>
	<EB08428982D3465B97C1B9D13A1183CE@gigabytex48dq>
Message-ID: <20080705083748.GA759@trillke.net>

Hi Baptiste, 

yes, it probably makes sense to truncate traceback output to
some 40 lines or so, at least for statements that have no
indentation.  (i CC the issue tracker and try to 
create an issue out of our mail conversation, might go wrong) 

holger

On Sat, Jul 05, 2008 at 09:32 +0200, Baptiste Lepilleur wrote:

> ----- Original Message ----- 
> From: "holger krekel" <holger at merlinux.de>
> To: "Baptiste Lepilleur" <blep at users.sourceforge.net>
> Cc: <py-dev at codespeak.net>
> Sent: Thursday, July 03, 2008 12:02 PM
> Subject: Re: [py-dev] py.test bug: large stack trace produced with 
> fullsource dump on import failure
> 
> 
> > Hi Baptiste,
> >
> > On Fri, Jun 27, 2008 at 10:45 +0200, Baptiste Lepilleur wrote:
> >> I have run into an issue with py.test which make it pretty much unsable 
> >> with
> >> the following scenario:
> >> - a test module import another module
> >> - the import fails due to an exception thrown by the other module
> >>
> >> This scenario raise two bugs (hopefully this is the scenario to reproduce
> >> this bug):
> >> - Py.test produces a stack trace with a full source dump of the imported
> >> module source
> >> - Information about the exception that caused the failure is missing.
> >>
> >> The source does not end line 2269, so my guess is that py.test dump the
> >> source until the source line where the exception was raised.
> >
> > exactly.
> >
> >> I believe py.test should truncate the source to show only the relevant 
> >> part,
> >> that is ignore the 2000 lines until the global variable declaration
> >> SCHEMA_SCHEMA in this case.
> >
> > Hum, in other cases it might be interesting to see the context, though.
> > E.g. if you have a couple of global statements where the
> > failing one depends on values produced by earlier ones.
> >
> I did not know this feature was present, though I've never seen it 
> triggering. Does it works with module level global variable ?
> 
> > I am not sure what the exact rule should be for such contexts
> > but your example showcases that we should try to improve,
> > indeed.
> 
> My rules of the thumb would be something like:
> If the trace at a given level of the stack is longer than two screen in 
> height, then truncates it and show only the relevant part. Otherwise, the 
> developper will likely spent more time analysing the trace than fixing the 
> test.
> How frequent is the use case you quote above ? I never stumbled on such a 
> case, though I don't write that much python code...
> 
> >
> > thanks & best,
> >
> > holger
> ---
> Baptiste Lepilleur <blep at users.sourceforge.net>
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

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

From blep at users.sourceforge.net  Sat Jul  5 10:49:02 2008
From: blep at users.sourceforge.net (Baptiste Lepilleur)
Date: Sat, 5 Jul 2008 10:49:02 +0200
Subject: [py-dev] py.test --looponfailing started failing on Windows...
References: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>
Message-ID: <D0AE7C05CDBA468EA328D8E87D9C570F@gigabytex48dq>

I managed to find where the readfrom code was. I added trace to the exec_net.Message class and it show that the initial 0x00 bytes is not recieved in readfrom.

* writeto:
header = (3, 1, 3, 0)
Length: 12, Binary: 0x['00', '03', '00', '01', '00', '00', '00', '03', '00', '00', '00', '00']

* readfrom:
header = (768, 256, 768, 0)
Length: 12, Binary: 0x['03', '00', '01', '00', '00', '00', '03', '00', '00', '00', '00', '00']

Now, were it gets weird is that I can get py.test -f working by adding the traces. I definetly get some non determinist behaviour there. The bug may be caused by some race condition that somehow has become more likely to occur.

Another stuff that I don't understand: 
I copied the mecanism from gateway.py to declare the "log" (the debug variable), and if the "log" variable is also named debug, then on the slave side, both message and gateway traces end-up in the message "log". The gateway log is created but never written into. Is it caused by the "magic" that send python code to the slave ?

Baptiste.
  ----- Original Message ----- 
  From: Baptiste Lepilleur 
  To: py-dev at codespeak.net 
  Sent: Saturday, July 05, 2008 10:03 AM
  Subject: [py-dev] py.test --looponfailing started failing on Windows...


  I'm stuck with this weird issue. py.test -f has worked perfectly for more than one month, but yesterday I got my first failure as shown below. The weird thing is that it restarted worked fine after failing a few times, but this morning it is impossible to get it working...

  Environment: Python 2.5.2 on Windows XP SP3 32 bits and py-0.9.1 install via setup.py.

  Below are the failure output when I start py.test -f, and the debug ouput of the gateway trace that I enabled. Anyone know how to get useful information about the remote exception (like source code... to help understand where this ValueError come from ?)

  I tried to run the gateway unit test, but they always get stuck. The strange thing is that it seems to be depend on how they are started with py.test: 
  If I starts the test with disabled stdout capture (py.test -v -s) , then the test remain stuck on:
   test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py,
  If I starts the test normally (py.test -v), then test run go farther but get stuck on:
  test_gateway.py:405  TestPopenGateway().test_chdir_separation
  Gateway debug trace for unit test do not show any ValueError exception...
  Unit tests output is at the end of the mail.

  Any help to understand where I should add traces in the code to understand what is going on would be greatly appreciated.

  Thanks,
  Baptiste.

  * The failure:
  E:\prg\py\App\sbuilder\build\src\sbuilder\testing>py.test.py  -f
  * opening PopenGateway:  C:\Python25\python.exe
  MASTER: initiated slave terminal session ->
  MASTER: send start info, topdir=E:\prg\py\App\sbuilder\build\src
  Traceback (most recent call last):
    File "E:\prg\py\App\sbuilder\build\src\sbuilder\testing\py.test.py", line 4, in <module>
      py.test.cmdline.main()
    File "c:\Python25\lib\site-packages\py\test\cmdline.py", line 15, in main
      failures = session.main()
    File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 82, in main
      failures = self.run_remote_session(failures)
    File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 111, in run_remote_session
      return channel.receive()
    File "C:\Python25\lib\site-packages\py\execnet\channel.py", line 175, in receive
      raise self._getremoteerror() or EOFError()
  EOFError

  I enabled the gateway trace I found:
  **** execnet-debug-3420:
  sending gateway bootstrap code
  Channel(3).__del__
  sent -> <Message.CHANNEL_LAST_MESSAGE channelid=3 ''>
  Channel(5).__del__
  sent -> <Message.CHANNEL_LAST_MESSAGE channelid=5 ''>
  sent -> <Message.CHANNEL_OPEN channelid=1 len=111>
  sent -> <Message.CHANNEL_DATA channelid=1 len=456>
  leaving <Thread(receiver, started daemon)>
  ====================cleaning up====================
  Channel(1).__del__


  *** execnet-debug-2308 
  Traceback (most recent call last):
    File "<string>", line 359, in _thread_receiver
    File "<string>", line 626, in readfrom
  ValueError: bad data format

  leaving <Thread(receiver, started daemon)>
  _servemain finished
  ====================cleaning up====================


  *** Results of running the unit tests for exec_net module
  C:\Python25\Lib\site-packages\py\execnet\testing>python c:\Python25\Lib\site-packages\py\bin\py.test -v
  inserting into sys.path: C:\Python25\Lib\site-packages
  ============================= test process starts =============================
  executable:   c:\Python25\python.exe  (2.5.2-final-0)
  using py lib: C:\Python25\Lib\site-packages\py <rev unknown>
  test target:  C:\Python25\Lib\site-packages\py\execnet\testing
  initial conf 0: C:\Python25\Lib\site-packages\py\test\defaultconftest.pyc
  initial conf 1: C:\Python25\Lib\site-packages\py\conftest.pyc


  + testmodule: C:\Python25\Lib\site-packages\py\execnet\testing\test_gateway.py
  register.py:20       test_getsource_import_modules[0] ok (0.00)
  register.py:20       test_getsource_import_modules[1] ok (0.00)
  register.py:20       test_getsource_import_modules[2] ok (0.00)
  register.py:20       test_getsource_import_modules[3] ok (0.00)
  register.py:20       test_getsource_import_modules[4] ok (0.00)
  test_gateway.py:17   test_getsource_no_colision ok (0.00)
  test_gateway.py:30   test_stdouterrin_setnull ok (0.02)
  test_gateway.py:45   TestMessage().test_wire_protocol ok (0.00)
  test_gateway.py:61   TestPureChannel().test_factory_create ok (0.00)
  test_gateway.py:67   TestPureChannel().test_factory_getitem ok (0.00)
  test_gateway.py:73   TestPureChannel().test_channel_timeouterror ok (0.02)
  test_gateway.py:85   TestPopenGateway().test_correct_setup ok (0.08)
  test_gateway.py:88   TestPopenGateway().test_repr_doesnt_crash ok (0.00)
  test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py ok (0.02)
  test_gateway.py:100  TestPopenGateway().test_remote_exec_waitclose ok (0.00)
  test_gateway.py:104  TestPopenGateway().test_remote_exec_waitclose_2 ok (0.00)
  test_gateway.py:108  TestPopenGateway().test_remote_exec_waitclose_noarg ok (0.00)
  test_gateway.py:112  TestPopenGateway().test_remote_exec_error_after_close ok (0.00)
  test_gateway.py:117  TestPopenGateway().test_remote_exec_channel_anonymous ok (0.00)
  test_gateway.py:126  TestPopenGateway().test_channel_close_and_then_receive_error ok (0.00)
  test_gateway.py:130  TestPopenGateway().test_channel_finish_and_then_EOFError ok (0.00)
  test_gateway.py:138  TestPopenGateway().test_channel_close_and_then_receive_error_multiple ok (0.00)

  test_gateway.py:144  TestPopenGateway().test_channel__local_close ok (0.00)
  test_gateway.py:149  TestPopenGateway().test_channel__local_close_error ok (0.00)
  test_gateway.py:155  TestPopenGateway().test_channel_error_reporting ok (0.00)
  test_gateway.py:166  TestPopenGateway().test_channel_syntax_error ok (0.00)
  test_gateway.py:175  TestPopenGateway().test_channel_iter ok (0.00)
  test_gateway.py:183  TestPopenGateway().test_channel_passing_over_channel ok (0.00)
  test_gateway.py:202  TestPopenGateway().test_channel_receiver_callback ok (0.00)
  test_gateway.py:217  TestPopenGateway().test_channel_callback_after_receive ok (0.02)
  test_gateway.py:233  TestPopenGateway().test_waiting_for_callbacks ok (0.22)
  test_gateway.py:245  TestPopenGateway().test_channel_callback_stays_active ok (0.75)
  test_gateway.py:275  TestPopenGateway().test_channel_callback_remote_freed ok (0.75)
  test_gateway.py:279  TestPopenGateway().test_channel_endmarker_callback ok (0.00)
  test_gateway.py:294  TestPopenGateway().test_remote_redirect_stdout ok (0.00)
  test_gateway.py:303  TestPopenGateway().test_remote_exec_redirect_multi ok (0.00)
  test_gateway.py:318  TestPopenGateway().test_channel_file ok (0.00)
  test_gateway.py:330  TestPopenGateway().test_channel_file_write_error ok (0.00)
  test_gateway.py:336  TestPopenGateway().test_channel_file_proxyclose ok (0.02)
  test_gateway.py:347  TestPopenGateway().test_confusion_from_os_write_stdout ok (0.00)
  test_gateway.py:361  TestPopenGateway().test_confusion_from_os_write_stderr ok (0.00)
  test_gateway.py:375  TestPopenGateway().test_non_reverse_execution ok (0.03)
  test_gateway.py:405  TestPopenGateway().test_chdir_separation ^C
  C:\Python25\Lib\site-packages\py\execnet\testing>

  ---
  Baptiste Lepilleur <blep at users.sourceforge.net>



------------------------------------------------------------------------------


  _______________________________________________
  py-dev mailing list
  py-dev at codespeak.net
  http://codespeak.net/mailman/listinfo/py-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20080705/9d4559cd/attachment-0001.htm 

From holger at merlinux.de  Sat Jul  5 11:01:39 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 5 Jul 2008 11:01:39 +0200
Subject: [py-dev] py.test --looponfailing started failing on Windows...
In-Reply-To: <D0AE7C05CDBA468EA328D8E87D9C570F@gigabytex48dq>
References: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>
	<D0AE7C05CDBA468EA328D8E87D9C570F@gigabytex48dq>
Message-ID: <20080705090139.GC759@trillke.net>

On Sat, Jul 05, 2008 at 10:49 +0200, Baptiste Lepilleur wrote:
> I managed to find where the readfrom code was. I added trace to the exec_net.Message class and it show that the initial 0x00 bytes is not recieved in readfrom.
> 
> * writeto:
> header = (3, 1, 3, 0)
> Length: 12, Binary: 0x['00', '03', '00', '01', '00', '00', '00', '03', '00', '00', '00', '00']
> 
> * readfrom:
> header = (768, 256, 768, 0)
> Length: 12, Binary: 0x['03', '00', '01', '00', '00', '00', '03', '00', '00', '00', '00', '00']

doesn't this look like a network versus host byte order issue?
Can't imagine how this will only sometimes happen, though. 

i am soon leaving for EP2008 so cannot dig deeper for now. 
let me know about any more observations. 

thanks & best, 

holger


> Now, were it gets weird is that I can get py.test -f working by adding the traces. I definetly get some non determinist behaviour there. The bug may be caused by some race condition that somehow has become more likely to occur.
> 
> Another stuff that I don't understand: 
> I copied the mecanism from gateway.py to declare the "log" (the debug variable), and if the "log" variable is also named debug, then on the slave side, both message and gateway traces end-up in the message "log". The gateway log is created but never written into. Is it caused by the "magic" that send python code to the slave ?
> 
> Baptiste.
>   ----- Original Message ----- 
>   From: Baptiste Lepilleur 
>   To: py-dev at codespeak.net 
>   Sent: Saturday, July 05, 2008 10:03 AM
>   Subject: [py-dev] py.test --looponfailing started failing on Windows...
> 
> 
>   I'm stuck with this weird issue. py.test -f has worked perfectly for more than one month, but yesterday I got my first failure as shown below. The weird thing is that it restarted worked fine after failing a few times, but this morning it is impossible to get it working...
> 
>   Environment: Python 2.5.2 on Windows XP SP3 32 bits and py-0.9.1 install via setup.py.
> 
>   Below are the failure output when I start py.test -f, and the debug ouput of the gateway trace that I enabled. Anyone know how to get useful information about the remote exception (like source code... to help understand where this ValueError come from ?)
> 
>   I tried to run the gateway unit test, but they always get stuck. The strange thing is that it seems to be depend on how they are started with py.test: 
>   If I starts the test with disabled stdout capture (py.test -v -s) , then the test remain stuck on:
>    test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py,
>   If I starts the test normally (py.test -v), then test run go farther but get stuck on:
>   test_gateway.py:405  TestPopenGateway().test_chdir_separation
>   Gateway debug trace for unit test do not show any ValueError exception...
>   Unit tests output is at the end of the mail.
> 
>   Any help to understand where I should add traces in the code to understand what is going on would be greatly appreciated.
> 
>   Thanks,
>   Baptiste.
> 
>   * The failure:
>   E:\prg\py\App\sbuilder\build\src\sbuilder\testing>py.test.py  -f
>   * opening PopenGateway:  C:\Python25\python.exe
>   MASTER: initiated slave terminal session ->
>   MASTER: send start info, topdir=E:\prg\py\App\sbuilder\build\src
>   Traceback (most recent call last):
>     File "E:\prg\py\App\sbuilder\build\src\sbuilder\testing\py.test.py", line 4, in <module>
>       py.test.cmdline.main()
>     File "c:\Python25\lib\site-packages\py\test\cmdline.py", line 15, in main
>       failures = session.main()
>     File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 82, in main
>       failures = self.run_remote_session(failures)
>     File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 111, in run_remote_session
>       return channel.receive()
>     File "C:\Python25\lib\site-packages\py\execnet\channel.py", line 175, in receive
>       raise self._getremoteerror() or EOFError()
>   EOFError
> 
>   I enabled the gateway trace I found:
>   **** execnet-debug-3420:
>   sending gateway bootstrap code
>   Channel(3).__del__
>   sent -> <Message.CHANNEL_LAST_MESSAGE channelid=3 ''>
>   Channel(5).__del__
>   sent -> <Message.CHANNEL_LAST_MESSAGE channelid=5 ''>
>   sent -> <Message.CHANNEL_OPEN channelid=1 len=111>
>   sent -> <Message.CHANNEL_DATA channelid=1 len=456>
>   leaving <Thread(receiver, started daemon)>
>   ====================cleaning up====================
>   Channel(1).__del__
> 
> 
>   *** execnet-debug-2308 
>   Traceback (most recent call last):
>     File "<string>", line 359, in _thread_receiver
>     File "<string>", line 626, in readfrom
>   ValueError: bad data format
> 
>   leaving <Thread(receiver, started daemon)>
>   _servemain finished
>   ====================cleaning up====================
> 
> 
>   *** Results of running the unit tests for exec_net module
>   C:\Python25\Lib\site-packages\py\execnet\testing>python c:\Python25\Lib\site-packages\py\bin\py.test -v
>   inserting into sys.path: C:\Python25\Lib\site-packages
>   ============================= test process starts =============================
>   executable:   c:\Python25\python.exe  (2.5.2-final-0)
>   using py lib: C:\Python25\Lib\site-packages\py <rev unknown>
>   test target:  C:\Python25\Lib\site-packages\py\execnet\testing
>   initial conf 0: C:\Python25\Lib\site-packages\py\test\defaultconftest.pyc
>   initial conf 1: C:\Python25\Lib\site-packages\py\conftest.pyc
> 
> 
>   + testmodule: C:\Python25\Lib\site-packages\py\execnet\testing\test_gateway.py
>   register.py:20       test_getsource_import_modules[0] ok (0.00)
>   register.py:20       test_getsource_import_modules[1] ok (0.00)
>   register.py:20       test_getsource_import_modules[2] ok (0.00)
>   register.py:20       test_getsource_import_modules[3] ok (0.00)
>   register.py:20       test_getsource_import_modules[4] ok (0.00)
>   test_gateway.py:17   test_getsource_no_colision ok (0.00)
>   test_gateway.py:30   test_stdouterrin_setnull ok (0.02)
>   test_gateway.py:45   TestMessage().test_wire_protocol ok (0.00)
>   test_gateway.py:61   TestPureChannel().test_factory_create ok (0.00)
>   test_gateway.py:67   TestPureChannel().test_factory_getitem ok (0.00)
>   test_gateway.py:73   TestPureChannel().test_channel_timeouterror ok (0.02)
>   test_gateway.py:85   TestPopenGateway().test_correct_setup ok (0.08)
>   test_gateway.py:88   TestPopenGateway().test_repr_doesnt_crash ok (0.00)
>   test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py ok (0.02)
>   test_gateway.py:100  TestPopenGateway().test_remote_exec_waitclose ok (0.00)
>   test_gateway.py:104  TestPopenGateway().test_remote_exec_waitclose_2 ok (0.00)
>   test_gateway.py:108  TestPopenGateway().test_remote_exec_waitclose_noarg ok (0.00)
>   test_gateway.py:112  TestPopenGateway().test_remote_exec_error_after_close ok (0.00)
>   test_gateway.py:117  TestPopenGateway().test_remote_exec_channel_anonymous ok (0.00)
>   test_gateway.py:126  TestPopenGateway().test_channel_close_and_then_receive_error ok (0.00)
>   test_gateway.py:130  TestPopenGateway().test_channel_finish_and_then_EOFError ok (0.00)
>   test_gateway.py:138  TestPopenGateway().test_channel_close_and_then_receive_error_multiple ok (0.00)
> 
>   test_gateway.py:144  TestPopenGateway().test_channel__local_close ok (0.00)
>   test_gateway.py:149  TestPopenGateway().test_channel__local_close_error ok (0.00)
>   test_gateway.py:155  TestPopenGateway().test_channel_error_reporting ok (0.00)
>   test_gateway.py:166  TestPopenGateway().test_channel_syntax_error ok (0.00)
>   test_gateway.py:175  TestPopenGateway().test_channel_iter ok (0.00)
>   test_gateway.py:183  TestPopenGateway().test_channel_passing_over_channel ok (0.00)
>   test_gateway.py:202  TestPopenGateway().test_channel_receiver_callback ok (0.00)
>   test_gateway.py:217  TestPopenGateway().test_channel_callback_after_receive ok (0.02)
>   test_gateway.py:233  TestPopenGateway().test_waiting_for_callbacks ok (0.22)
>   test_gateway.py:245  TestPopenGateway().test_channel_callback_stays_active ok (0.75)
>   test_gateway.py:275  TestPopenGateway().test_channel_callback_remote_freed ok (0.75)
>   test_gateway.py:279  TestPopenGateway().test_channel_endmarker_callback ok (0.00)
>   test_gateway.py:294  TestPopenGateway().test_remote_redirect_stdout ok (0.00)
>   test_gateway.py:303  TestPopenGateway().test_remote_exec_redirect_multi ok (0.00)
>   test_gateway.py:318  TestPopenGateway().test_channel_file ok (0.00)
>   test_gateway.py:330  TestPopenGateway().test_channel_file_write_error ok (0.00)
>   test_gateway.py:336  TestPopenGateway().test_channel_file_proxyclose ok (0.02)
>   test_gateway.py:347  TestPopenGateway().test_confusion_from_os_write_stdout ok (0.00)
>   test_gateway.py:361  TestPopenGateway().test_confusion_from_os_write_stderr ok (0.00)
>   test_gateway.py:375  TestPopenGateway().test_non_reverse_execution ok (0.03)
>   test_gateway.py:405  TestPopenGateway().test_chdir_separation ^C
>   C:\Python25\Lib\site-packages\py\execnet\testing>
> 
>   ---
>   Baptiste Lepilleur <blep at users.sourceforge.net>
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
>   _______________________________________________
>   py-dev mailing list
>   py-dev at codespeak.net
>   http://codespeak.net/mailman/listinfo/py-dev

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


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

From blep at users.sourceforge.net  Sat Jul  5 11:40:25 2008
From: blep at users.sourceforge.net (Baptiste Lepilleur)
Date: Sat, 5 Jul 2008 11:40:25 +0200
Subject: [py-dev] py.test --looponfailing started failing on Windows...
References: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>
	<20080705083118.GZ759@trillke.net>
Message-ID: <B4776D9A5DEC44529F162C11D2037433@gigabytex48dq>

----- Original Message ----- 
From: "holger krekel" <holger at merlinux.de>
To: "Baptiste Lepilleur" <blep at users.sourceforge.net>
Cc: <py-dev at codespeak.net>
Sent: Saturday, July 05, 2008 10:31 AM
Subject: Re: [py-dev] py.test --looponfailing started failing on Windows...


> Hi Baptiste,
>
> thanks for your good report.  Debugging such issues is often
> tedious.  but let's try.  I assume that you have no changes
> to the system or the python version that you are aware of.

Yes, and it's getting really weird. The bug seems to disappear if I put too 
much trace (which make it tricky to figure out). Well, at least it give me a 
work-around for the mean-time.

> Before doing anything more, please do a "py/bin/py.cleanup"
> on your complete project - this erases all .pyc files.
> and check if the problem goes away.

Unfortunately, it had no effect.
---
Baptiste Lepilleur <blep at users.sourceforge.net>


From schmir at gmail.com  Mon Jul  7 07:56:29 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Mon, 7 Jul 2008 07:56:29 +0200
Subject: [py-dev] bug in py.test.collect
Message-ID: <932f8baf0807062256h421d6f2fif2c051ca0db5120c@mail.gmail.com>

I got the following traceback, when running py.test on one of my test files.
I haven't investigated any further...

____________________________ entrypoint: TestEnv() _____________________________

    def runtraced(self, colitem):
        if self.shouldclose():
            raise Exit, "received external close signal"

        outcome = None
        colitem.startcapture()
        try:
            self.start(colitem)
            try:
                try:
                    if colitem._stickyfailure:
                        raise colitem._stickyfailure
>                   outcome = self.run(colitem)

[/home/ralf/py26/lib/python2.6/site-packages/py/test/session.py:84]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

[/home/ralf/py26/lib/python2.6/site-packages/py/test/session.py:107]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

[/home/ralf/py26/lib/python2.6/site-packages/py/test/collect.py:336]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

[/home/ralf/py26/lib/python2.6/site-packages/py/test/collect.py:328]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

[/home/ralf/py26/lib/python2.6/site-packages/py/test/collect.py:298]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

[/home/ralf/py26/lib/python2.6/site-packages/py/test/collect.py:105]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

[/home/ralf/py26/lib/python2.6/site-packages/py/test/collect.py:436]

From schmir at gmail.com  Mon Jul  7 08:06:04 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Mon, 7 Jul 2008 08:06:04 +0200
Subject: [py-dev] bug in py.test.collect
In-Reply-To: <932f8baf0807062256h421d6f2fif2c051ca0db5120c@mail.gmail.com>
References: <932f8baf0807062256h421d6f2fif2c051ca0db5120c@mail.gmail.com>
Message-ID: <932f8baf0807062306x2f568b15na8fe8d0fecc96d3b@mail.gmail.com>

On Mon, Jul 7, 2008 at 7:56 AM, Ralf Schmitt <schmir at gmail.com> wrote:
> I got the following traceback, when running py.test on one of my test files.
> I haven't investigated any further...
>

Now I did, it's apparently trying to run TestEnv as a test. But this
was never intender to be as test case.

Sorry for the noise,
- Ralf


> ____________________________ entrypoint: TestEnv() _____________________________
>

From monopocalypse+py-dev at gmail.com  Sat Jul 12 00:50:12 2008
From: monopocalypse+py-dev at gmail.com (Matthew Edwards)
Date: Sat, 12 Jul 2008 10:50:12 +1200
Subject: [py-dev] py.test --looponfailing IOError
Message-ID: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>

Hi

I'm running py 0.9.1 (from tarfile) on Windows XP. I've written a
couple of simple tests, which are in a folder called test. Whenever I
do "py.test --looponfailing test/" I get the following output:


inserting into sys.path: C:\Program Files\Python\Lib\site-packages
* opening PopenGateway:  C:\Program Files\Python\python.exe
Traceback (most recent call last):
  File "C:\Program
Files\Python\Lib\site-packages\py\bin\win32\\..\py.test", line 4, in
<module>
    py.test.cmdline.main()
  File "C:\Program Files\Python\Lib\site-packages\py\test\cmdline.py",
line 15, in main
    failures = session.main()
  File "C:\Program
Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 82,
in main
    failures = self.run_remote_session(failures)
  File "C:\Program
Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 100,
in run_remote_session

    gw, topdir = self._initslavegateway()
  File "C:\Program
Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 97,
in _initslavegateway
    return py.execnet.PopenGateway(self.executable), topdir
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\register.py", line 66, in
__init__
    super(PopenGateway, self).__init__(cmd)
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\register.py", line 55, in
__init__
    super(PopenCmdGateway, self).__init__(io=io)
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\register.py", line 29, in
__init__
    self._remote_bootstrap_gateway(io)
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\register.py", line 80, in
_remote_bootstrap_gateway
    super(PopenGateway, self)._remote_bootstrap_gateway(io, s)
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\register.py", line 49, in
_remote_bootstrap_gateway
    io.write('%r\n' % source)
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\inputoutput.py", line 95, in
write
    self.outfile.write(data)
IOError: [Errno 22] Invalid argument

I can run the tests without --looponfailing.

Any help appreciated
Matthew

From holger at merlinux.de  Sat Jul 12 07:01:38 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 12 Jul 2008 07:01:38 +0200
Subject: [py-dev] py.test --looponfailing IOError
In-Reply-To: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>
References: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>
Message-ID: <20080712050137.GU759@trillke.net>

Hello Matthew, 

this seems to be a problem with the lower level network communication part. 
also had other reports pointing to that.  I aim to look into
this next week when i am back from EuroPython ... 

can you meanwhile post your Python version and attach the test
file that triggered the problems? 

best & thanks,

holger


On Sat, Jul 12, 2008 at 10:50 +1200, Matthew Edwards wrote:
> Hi
> 
> I'm running py 0.9.1 (from tarfile) on Windows XP. I've written a
> couple of simple tests, which are in a folder called test. Whenever I
> do "py.test --looponfailing test/" I get the following output:
> 
> 
> inserting into sys.path: C:\Program Files\Python\Lib\site-packages
> * opening PopenGateway:  C:\Program Files\Python\python.exe
> Traceback (most recent call last):
>   File "C:\Program
> Files\Python\Lib\site-packages\py\bin\win32\\..\py.test", line 4, in
> <module>
>     py.test.cmdline.main()
>   File "C:\Program Files\Python\Lib\site-packages\py\test\cmdline.py",
> line 15, in main
>     failures = session.main()
>   File "C:\Program
> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 82,
> in main
>     failures = self.run_remote_session(failures)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 100,
> in run_remote_session
> 
>     gw, topdir = self._initslavegateway()
>   File "C:\Program
> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 97,
> in _initslavegateway
>     return py.execnet.PopenGateway(self.executable), topdir
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\register.py", line 66, in
> __init__
>     super(PopenGateway, self).__init__(cmd)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\register.py", line 55, in
> __init__
>     super(PopenCmdGateway, self).__init__(io=io)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\register.py", line 29, in
> __init__
>     self._remote_bootstrap_gateway(io)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\register.py", line 80, in
> _remote_bootstrap_gateway
>     super(PopenGateway, self)._remote_bootstrap_gateway(io, s)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\register.py", line 49, in
> _remote_bootstrap_gateway
>     io.write('%r\n' % source)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\inputoutput.py", line 95, in
> write
>     self.outfile.write(data)
> IOError: [Errno 22] Invalid argument
> 
> I can run the tests without --looponfailing.
> 
> Any help appreciated
> Matthew
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

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

From monopocalypse+py-dev at gmail.com  Sat Jul 12 08:03:04 2008
From: monopocalypse+py-dev at gmail.com (Matthew Edwards)
Date: Sat, 12 Jul 2008 18:03:04 +1200
Subject: [py-dev] py.test --looponfailing IOError
In-Reply-To: <20080712050137.GU759@trillke.net>
References: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>
	<20080712050137.GU759@trillke.net>
Message-ID: <4025a36d0807112303l357c3cc9v58f12328e41e4035@mail.gmail.com>

Hi

I'm using Python 2.5.2 (sorry, forgot to mention). Any test file will
cause the error - an empty folder will not, but a folder with an empty
file called "test_1.py" will. Running with an empty folder and then
adding a test file will also.

I've attached the files anyway (slightly cut-down versions which still
cause the error).

I've run what looks like the py.execnet test suite
(site-packages\py\execnet\testing), and most of the tests fail, so
I've attached the log of that (zipped).

Thanks
Matthew

On Sat, Jul 12, 2008 at 5:01 PM, holger krekel <holger at merlinux.de> wrote:
>
> Hello Matthew,
>
> this seems to be a problem with the lower level network communication part.
> also had other reports pointing to that.  I aim to look into
> this next week when i am back from EuroPython ...
>
> can you meanwhile post your Python version and attach the test
> file that triggered the problems?
>
> best & thanks,
>
> holger
>
>
> On Sat, Jul 12, 2008 at 10:50 +1200, Matthew Edwards wrote:
> > Hi
> >
> > I'm running py 0.9.1 (from tarfile) on Windows XP. I've written a
> > couple of simple tests, which are in a folder called test. Whenever I
> > do "py.test --looponfailing test/" I get the following output:
> >
> >
> > inserting into sys.path: C:\Program Files\Python\Lib\site-packages
> > * opening PopenGateway:  C:\Program Files\Python\python.exe
> > Traceback (most recent call last):
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\bin\win32\\..\py.test", line 4, in
> > <module>
> >     py.test.cmdline.main()
> >   File "C:\Program Files\Python\Lib\site-packages\py\test\cmdline.py",
> > line 15, in main
> >     failures = session.main()
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 82,
> > in main
> >     failures = self.run_remote_session(failures)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 100,
> > in run_remote_session
> >
> >     gw, topdir = self._initslavegateway()
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 97,
> > in _initslavegateway
> >     return py.execnet.PopenGateway(self.executable), topdir
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\register.py", line 66, in
> > __init__
> >     super(PopenGateway, self).__init__(cmd)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\register.py", line 55, in
> > __init__
> >     super(PopenCmdGateway, self).__init__(io=io)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\register.py", line 29, in
> > __init__
> >     self._remote_bootstrap_gateway(io)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\register.py", line 80, in
> > _remote_bootstrap_gateway
> >     super(PopenGateway, self)._remote_bootstrap_gateway(io, s)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\register.py", line 49, in
> > _remote_bootstrap_gateway
> >     io.write('%r\n' % source)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\inputoutput.py", line 95, in
> > write
> >     self.outfile.write(data)
> > IOError: [Errno 22] Invalid argument
> >
> > I can run the tests without --looponfailing.
> >
> > Any help appreciated
> > Matthew
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> >
>
> --
> collaborative expert contracting: http://merlinux.eu
> pylib py.test/greenlets/svn APIs: http://pylib.org
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proto.py
Type: text/x-python
Size: 1003 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20080712/91d950a8/attachment-0002.py 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_proto.py
Type: text/x-python
Size: 461 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20080712/91d950a8/attachment-0003.py 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.log.zip
Type: application/zip
Size: 4613 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20080712/91d950a8/attachment-0001.zip 

From blep at users.sourceforge.net  Sun Jul 20 17:25:32 2008
From: blep at users.sourceforge.net (Baptiste Lepilleur)
Date: Sun, 20 Jul 2008 17:25:32 +0200
Subject: [py-dev] py.test --looponfailing IOError
References: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>
	<20080712050137.GU759@trillke.net>
Message-ID: <AF559A9AFB754F50A96AF2EEE79A2E95@gigabytex48dq>

Attached is the VERY dirty patch I made to try to diagnose the problem (I 
running with it). It adds debug traces and a magic number at the begginning 
of each packet header. Though, I haven't been able to reproduce it since the 
last time it occurred. The probability of occurrence seems to be reduced 
with the added trace, but it still occurred a few times with the traces.

The main possible source I see to explain this random behavior is a race 
condition. I find it is suspicious that it always occurs on the first byte 
following the bootstrap code send on stdin. The only candidate I've seen in 
the code is that stdin/stdout are set to binary mode at the end of the 
bootstrap code, but I don't know if this could cause a byte to be lost.

You'll need to create a c:\temp\_execnet directory (debug traces are dumped 
there).

----- Original Message ----- 
From: "holger krekel" <holger at merlinux.de>
To: "Matthew Edwards" <monopocalypse+py-dev at gmail.com>
Cc: <py-dev at codespeak.net>
Sent: Saturday, July 12, 2008 7:01 AM
Subject: Re: [py-dev] py.test --looponfailing IOError


> Hello Matthew,
>
> this seems to be a problem with the lower level network communication 
> part.
> also had other reports pointing to that.  I aim to look into
> this next week when i am back from EuroPython ...
>
> can you meanwhile post your Python version and attach the test
> file that triggered the problems?
>
> best & thanks,
>
> holger
>
>
> On Sat, Jul 12, 2008 at 10:50 +1200, Matthew Edwards wrote:
>> Hi
>>
>> I'm running py 0.9.1 (from tarfile) on Windows XP. I've written a
>> couple of simple tests, which are in a folder called test. Whenever I
>> do "py.test --looponfailing test/" I get the following output:
>>
>>
>> inserting into sys.path: C:\Program Files\Python\Lib\site-packages
>> * opening PopenGateway:  C:\Program Files\Python\python.exe
>> Traceback (most recent call last):
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\bin\win32\\..\py.test", line 4, in
>> <module>
>>     py.test.cmdline.main()
>>   File "C:\Program Files\Python\Lib\site-packages\py\test\cmdline.py",
>> line 15, in main
>>     failures = session.main()
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 82,
>> in main
>>     failures = self.run_remote_session(failures)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 100,
>> in run_remote_session
>>
>>     gw, topdir = self._initslavegateway()
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 97,
>> in _initslavegateway
>>     return py.execnet.PopenGateway(self.executable), topdir
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\register.py", line 66, in
>> __init__
>>     super(PopenGateway, self).__init__(cmd)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\register.py", line 55, in
>> __init__
>>     super(PopenCmdGateway, self).__init__(io=io)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\register.py", line 29, in
>> __init__
>>     self._remote_bootstrap_gateway(io)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\register.py", line 80, in
>> _remote_bootstrap_gateway
>>     super(PopenGateway, self)._remote_bootstrap_gateway(io, s)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\register.py", line 49, in
>> _remote_bootstrap_gateway
>>     io.write('%r\n' % source)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\inputoutput.py", line 95, in
>> write
>>     self.outfile.write(data)
>> IOError: [Errno 22] Invalid argument
>>
>> I can run the tests without --looponfailing.
>>
>> Any help appreciated
>> Matthew
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>
>
> -- 
> collaborative expert contracting: http://merlinux.eu
> pylib py.test/greenlets/svn APIs: http://pylib.org
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: execnet.patch
Type: application/octet-stream
Size: 5615 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20080720/192f1e20/attachment.obj 

From haraldarminmassa at gmail.com  Tue Jul 22 12:15:01 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 22 Jul 2008 12:15:01 +0200
Subject: [py-dev] patch to allow usage of py.lib within non-administrator
	account on windows
Message-ID: <7be3f35d0807220315o5ef83322lfe1ff68d4a87246@mail.gmail.com>

Hello!

atm. py.lib uses

os.tmpfile()

within fdcapture.py.


On windows os.tmpfile() tries to create the file within the root of
c:\; and it is quite good practice to disallow write access to this
directory for non-admin users (as this avoids killing crucial system
files)

So installation on windows using an user without write-access to c:\,
even setup.py fails with "permission.denied"

More info in:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/4aa54e927f11bbc3?tvc=2


It is fixable by using:

def maketmpfile(self):
        """ create a temporary file
        """
        #~ f = os.tmpfile()
        f=tempfile.TemporaryFile()
        newf = py.io.dupfile(f)
        f.close()
        return newf

    def writeorg(self, str):
        """ write a string to the original file descriptor
        """
        tempfp = tempfile.TemporaryFile()
        try:
            os.dup2(self._savefd, tempfp.fileno())
            tempfp.write(str)
        finally:
            tempfp.close()

within lines 42ff of py/io/fdcapture.py, of course after importing tempfile.

I submit this patch into public domain.

Harald

-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pidgeon
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!

From holger at merlinux.eu  Tue Jul 22 15:58:21 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Jul 2008 15:58:21 +0200
Subject: [py-dev] patch to allow usage of py.lib
	within	non-administrator account on windows
In-Reply-To: <7be3f35d0807220315o5ef83322lfe1ff68d4a87246@mail.gmail.com>
References: <7be3f35d0807220315o5ef83322lfe1ff68d4a87246@mail.gmail.com>
Message-ID: <20080722135821.GC22324@trillke.net>

Hi Harald! 

thanks for the report.  I think this got fixed in 0.9.1 - 
are you using 0.9.0, maybe?  

cheers,

holger

On Tue, Jul 22, 2008 at 12:15 +0200, Harald Armin Massa wrote:
> Hello!
> 
> atm. py.lib uses
> 
> os.tmpfile()
> 
> within fdcapture.py.
> 
> 
> On windows os.tmpfile() tries to create the file within the root of
> c:\; and it is quite good practice to disallow write access to this
> directory for non-admin users (as this avoids killing crucial system
> files)
> 
> So installation on windows using an user without write-access to c:\,
> even setup.py fails with "permission.denied"
> 
> More info in:
> 
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/4aa54e927f11bbc3?tvc=2
> 
> 
> It is fixable by using:
> 
> def maketmpfile(self):
>         """ create a temporary file
>         """
>         #~ f = os.tmpfile()
>         f=tempfile.TemporaryFile()
>         newf = py.io.dupfile(f)
>         f.close()
>         return newf
> 
>     def writeorg(self, str):
>         """ write a string to the original file descriptor
>         """
>         tempfp = tempfile.TemporaryFile()
>         try:
>             os.dup2(self._savefd, tempfp.fileno())
>             tempfp.write(str)
>         finally:
>             tempfp.close()
> 
> within lines 42ff of py/io/fdcapture.py, of course after importing tempfile.
> 
> I submit this patch into public domain.
> 
> Harald
> 
> -- 
> GHUM Harald Massa
> persuadere et programmare
> Harald Armin Massa
> Spielberger Stra?e 49
> 70435 Stuttgart
> 0173/9409607
> no fx, no carrier pidgeon
> -
> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

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

From haraldarminmassa at gmail.com  Tue Jul 22 16:15:04 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 22 Jul 2008 16:15:04 +0200
Subject: [py-dev] patch to allow usage of py.lib within
	non-administrator account on windows
In-Reply-To: <20080722135821.GC22324@trillke.net>
References: <7be3f35d0807220315o5ef83322lfe1ff68d4a87246@mail.gmail.com>
	<20080722135821.GC22324@trillke.net>
Message-ID: <7be3f35d0807220715t5e8c2e71lbd9fc9bdeb37d2e2@mail.gmail.com>

I am using a svn checkout ...

svn co http://codespeak.net/svn/py/dist py-dist



On Tue, Jul 22, 2008 at 15:58, holger krekel <holger at merlinux.eu> wrote:
> Hi Harald!
>
> thanks for the report.  I think this got fixed in 0.9.1 -
> are you using 0.9.0, maybe?
>
> cheers,
>
> holger
>
> On Tue, Jul 22, 2008 at 12:15 +0200, Harald Armin Massa wrote:
>> Hello!
>>
>> atm. py.lib uses
>>
>> os.tmpfile()
>>
>> within fdcapture.py.
>>
>>
>> On windows os.tmpfile() tries to create the file within the root of
>> c:\; and it is quite good practice to disallow write access to this
>> directory for non-admin users (as this avoids killing crucial system
>> files)
>>
>> So installation on windows using an user without write-access to c:\,
>> even setup.py fails with "permission.denied"
>>
>> More info in:
>>
>> http://groups.google.com/group/comp.lang.python/browse_thread/thread/4aa54e927f11bbc3?tvc=2
>>
>>
>> It is fixable by using:
>>
>> def maketmpfile(self):
>>         """ create a temporary file
>>         """
>>         #~ f = os.tmpfile()
>>         f=tempfile.TemporaryFile()
>>         newf = py.io.dupfile(f)
>>         f.close()
>>         return newf
>>
>>     def writeorg(self, str):
>>         """ write a string to the original file descriptor
>>         """
>>         tempfp = tempfile.TemporaryFile()
>>         try:
>>             os.dup2(self._savefd, tempfp.fileno())
>>             tempfp.write(str)
>>         finally:
>>             tempfp.close()
>>
>> within lines 42ff of py/io/fdcapture.py, of course after importing tempfile.
>>
>> I submit this patch into public domain.
>>
>> Harald
>>
>> --
>> GHUM Harald Massa
>> persuadere et programmare
>> Harald Armin Massa
>> Spielberger Stra?e 49
>> 70435 Stuttgart
>> 0173/9409607
>> no fx, no carrier pidgeon
>> -
>> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>
>
> --
> collaborative expert contracting: http://merlinux.eu
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> pylib py.test/greenlets/svn APIs: http://pylib.org
>



-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pidgeon
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!

From holger at merlinux.eu  Tue Jul 22 16:32:01 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Jul 2008 16:32:01 +0200
Subject: [py-dev] patch to allow usage of py.lib
	within	non-administrator account on windows
In-Reply-To: <7be3f35d0807220715t5e8c2e71lbd9fc9bdeb37d2e2@mail.gmail.com>
References: <7be3f35d0807220315o5ef83322lfe1ff68d4a87246@mail.gmail.com>
	<20080722135821.GC22324@trillke.net>
	<7be3f35d0807220715t5e8c2e71lbd9fc9bdeb37d2e2@mail.gmail.com>
Message-ID: <20080722143201.GD22324@trillke.net>

On Tue, Jul 22, 2008 at 16:15 +0200, Harald Armin Massa wrote:
> I am using a svn checkout ...
> 
> svn co http://codespeak.net/svn/py/dist py-dist

i now synced py/release/0.9.1 to py/dist. 
Embarassingly, dist was even older than 0.9.1.

so i hope you now have a better version and things work. 

holger

> On Tue, Jul 22, 2008 at 15:58, holger krekel <holger at merlinux.eu> wrote:
> > Hi Harald!
> >
> > thanks for the report.  I think this got fixed in 0.9.1 -
> > are you using 0.9.0, maybe?
> >
> > cheers,
> >
> > holger
> >
> > On Tue, Jul 22, 2008 at 12:15 +0200, Harald Armin Massa wrote:
> >> Hello!
> >>
> >> atm. py.lib uses
> >>
> >> os.tmpfile()
> >>
> >> within fdcapture.py.
> >>
> >>
> >> On windows os.tmpfile() tries to create the file within the root of
> >> c:\; and it is quite good practice to disallow write access to this
> >> directory for non-admin users (as this avoids killing crucial system
> >> files)
> >>
> >> So installation on windows using an user without write-access to c:\,
> >> even setup.py fails with "permission.denied"
> >>
> >> More info in:
> >>
> >> http://groups.google.com/group/comp.lang.python/browse_thread/thread/4aa54e927f11bbc3?tvc=2
> >>
> >>
> >> It is fixable by using:
> >>
> >> def maketmpfile(self):
> >>         """ create a temporary file
> >>         """
> >>         #~ f = os.tmpfile()
> >>         f=tempfile.TemporaryFile()
> >>         newf = py.io.dupfile(f)
> >>         f.close()
> >>         return newf
> >>
> >>     def writeorg(self, str):
> >>         """ write a string to the original file descriptor
> >>         """
> >>         tempfp = tempfile.TemporaryFile()
> >>         try:
> >>             os.dup2(self._savefd, tempfp.fileno())
> >>             tempfp.write(str)
> >>         finally:
> >>             tempfp.close()
> >>
> >> within lines 42ff of py/io/fdcapture.py, of course after importing tempfile.
> >>
> >> I submit this patch into public domain.
> >>
> >> Harald
> >>
> >> --
> >> GHUM Harald Massa
> >> persuadere et programmare
> >> Harald Armin Massa
> >> Spielberger Stra?e 49
> >> 70435 Stuttgart
> >> 0173/9409607
> >> no fx, no carrier pidgeon
> >> -
> >> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
> >> _______________________________________________
> >> py-dev mailing list
> >> py-dev at codespeak.net
> >> http://codespeak.net/mailman/listinfo/py-dev
> >>
> >
> > --
> > collaborative expert contracting: http://merlinux.eu
> > PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> > pylib py.test/greenlets/svn APIs: http://pylib.org
> >
> 
> 
> 
> -- 
> GHUM Harald Massa
> persuadere et programmare
> Harald Armin Massa
> Spielberger Stra?e 49
> 70435 Stuttgart
> 0173/9409607
> no fx, no carrier pidgeon
> -
> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
> 

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

From haraldarminmassa at gmail.com  Tue Jul 22 17:45:47 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 22 Jul 2008 17:45:47 +0200
Subject: [py-dev] pytest -r does not work ... even with pypy present
Message-ID: <7be3f35d0807220845g4685f1f3r39599880c4914c31@mail.gmail.com>

trying to use pytest with -r to run a browser and keep looking on my tests.

Without pypy installed: it fails with an exception of "skip "pypy not found")

with pypy checked out and put into pythonpath:

C:\ham\ibox25>pytest -r parsvalue.py
Server started, listening on port 1432


import py.__.test.rsession.webjs
from pypy.translator.js.helper import __show_traceback
from pypy.rlib.nonconst import NonConstant as NonConst


def some_strange_function_which_will_never_be_called():

    py.__.test.rsession.webjs.main()
    py.__.test.rsession.webjs.show_skip(NonConstant('aa'))
    py.__.test.rsession.webjs.show_traceback(NonConstant('aa'))
    py.__.test.rsession.webjs.show_info(NonConstant('aa'))
    py.__.test.rsession.webjs.hide_info()
    py.__.test.rsession.webjs.show_host(NonConstant('aa'))
    py.__.test.rsession.webjs.hide_host()
    py.__.test.rsession.webjs.hide_messagebox()
    py.__.test.rsession.webjs.opt_scroll()

[translation:info] Annotating&simplifying...
[translation:info] with policy: pypy.translator.js.main.JsPolicy

[translation:ERROR] Error:
[translation:ERROR]  UnboundLocalError: local variable 'c' referenced before ass
ignment
[translation] start debugger...
Traceback (most recent call last):
  File "C:\Python25\lib\SocketServer.py", line 222, in handle_request
    self.process_request(request, client_address)
  File "C:\Python25\lib\SocketServer.py", line 241, in process_request
    self.finish_request(request, client_address)
  File "C:\Python25\lib\SocketServer.py", line 254, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "C:\Python25\lib\SocketServer.py", line 522, in __init__
    self.handle()
  File "C:\Python25\lib\BaseHTTPServer.py", line 316, in handle
    self.handle_one_request()
  File "C:\Python25\lib\BaseHTTPServer.py", line 310, in handle_one_request
    method()
  File "c:\libraries\pypy-dist\py\test\rsession\web.py", line 371, in do_GET
    method_to_call()
  File "c:\libraries\pypy-dist\py\test\rsession\web.py", line 408, in run_jssour
ce
    open(str(js_name), "w").write(javascript_source)
TypeError: argument 1 must be string or read-only character buffer, not None







-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pidgeon
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!

From haraldarminmassa at gmail.com  Tue Jul 22 18:13:53 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 22 Jul 2008 18:13:53 +0200
Subject: [py-dev] pytest -f fails on windows (with pypy-1.0.0 in pythonpath)
Message-ID: <7be3f35d0807220913ob5e7e71xf3f7feb244e34feb@mail.gmail.com>

C:\ham\ibox25>pytest -f
* opening PopenGateway:  C:\Python25\python.exe
MASTER: initiated slave terminal session ->
MASTER: send start info, topdir=C:\ham\ibox25
Traceback (most recent call last):
  File "C:\Python25\Scripts\\py.test", line 4, in <module>
    py.test.cmdline.main()
  File "c:\libraries\pypy-1.0.0\py\test\cmdline.py", line 15, in main
    failures = session.main()
  File "c:\libraries\pypy-1.0.0\py\test\terminal\remote.py", line 82, in main
    failures = self.run_remote_session(failures)
  File "c:\libraries\pypy-1.0.0\py\test\terminal\remote.py", line 111, in run_re
mote_session
    return channel.receive()
  File "c:\libraries\pypy-1.0.0\py\execnet\channel.py", line 175, in receive
    raise self._getremoteerror() or EOFError()
EOFError

-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pidgeon
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!

From haraldarminmassa at gmail.com  Tue Jul 22 18:15:16 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 22 Jul 2008 18:15:16 +0200
Subject: [py-dev] pytest -f fails on windows (without pypy-1.0.0 in
	pythonpath, another error)
Message-ID: <7be3f35d0807220915l24e4425an56a878fe99fa44c9@mail.gmail.com>

C:\ham\ibox25>pytest -f
* opening PopenGateway:  C:\Python25\python.exe
MASTER: initiated slave terminal session ->
MASTER: send start info, topdir=C:\ham\ibox25
Traceback (most recent call last):
  File "C:\Python25\Scripts\\py.test", line 4, in <module>
    py.test.cmdline.main()
  File "C:\Python25\Lib\site-packages\py\test\cmdline.py", line 15, in main
    failures = session.main()
  File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 82, in m
ain
    failures = self.run_remote_session(failures)
  File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 111, in
run_remote_session
    return channel.receive()
  File "C:\Python25\Lib\site-packages\py\execnet\channel.py", line 175, in recei
ve
    raise self._getremoteerror() or EOFError()
EOFError

-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pidgeon
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!

From holger at merlinux.eu  Tue Jul 22 19:08:46 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Jul 2008 19:08:46 +0200
Subject: [py-dev] pytest -r does not work ... even with pypy present
In-Reply-To: <7be3f35d0807220845g4685f1f3r39599880c4914c31@mail.gmail.com>
References: <7be3f35d0807220845g4685f1f3r39599880c4914c31@mail.gmail.com>
Message-ID: <20080722170846.GH22324@trillke.net>

Hi Harald, 

On Tue, Jul 22, 2008 at 17:45 +0200, Harald Armin Massa wrote:
> trying to use pytest with -r to run a browser and keep looking on my tests.
> 
> Without pypy installed: it fails with an exception of "skip "pypy not found")
> 
> with pypy checked out and put into pythonpath:
> 
> C:\ham\ibox25>pytest -r parsvalue.py
> Server started, listening on port 1432
> 
> 
> import py.__.test.rsession.webjs
> from pypy.translator.js.helper import __show_traceback
> from pypy.rlib.nonconst import NonConstant as NonConst

huah!  py.test should not require pypy here
but use the "source.js" that comes with package. 

I just fixed this with r56717 in http://codespeak.net/svn/py/dist 

So "py.test -r" should work now, also does on my windows installation. 
that mode is quite experimental but i think it's a very useful 
frontend in principle. 

best, holger

From holger at merlinux.de  Tue Jul 22 20:48:08 2008
From: holger at merlinux.de (holger krekel)
Date: Tue, 22 Jul 2008 20:48:08 +0200
Subject: [py-dev] py.test --looponfailing IOError
In-Reply-To: <AF559A9AFB754F50A96AF2EEE79A2E95@gigabytex48dq>
References: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>
	<20080712050137.GU759@trillke.net>
	<AF559A9AFB754F50A96AF2EEE79A2E95@gigabytex48dq>
Message-ID: <20080722184808.GI22324@trillke.net>

Hi Baptiste, hi Matthew, 

On Sun, Jul 20, 2008 at 17:25 +0200, Baptiste Lepilleur wrote:
> The main possible source I see to explain this random behavior is a race  
> condition. I find it is suspicious that it always occurs on the first 
> byte following the bootstrap code send on stdin. The only candidate I've 
> seen in the code is that stdin/stdout are set to binary mode at the end 
> of the bootstrap code, but I don't know if this could cause a byte to be 
> lost.

well, i don't know either but i think it was a good hint!

If i now set binary modes as early as possible on both sides
then things seem to work (i also had the problem that Matthew
got with "py.test -f" consistently and now it's gone,
and py.test py\execnet tests partially failed on my 
installation and now they pass). 

Could you maybe svn-checkout 

    http://codespeak.net/svn/py/release/0.9.x 

and after a "setup.py install" report back if it helps? 

cheers,

holger


> You'll need to create a c:\temp\_execnet directory (debug traces are 
> dumped there).
>
> ----- Original Message ----- From: "holger krekel" <holger at merlinux.de>
> To: "Matthew Edwards" <monopocalypse+py-dev at gmail.com>
> Cc: <py-dev at codespeak.net>
> Sent: Saturday, July 12, 2008 7:01 AM
> Subject: Re: [py-dev] py.test --looponfailing IOError
>
>
>> Hello Matthew,
>>
>> this seems to be a problem with the lower level network communication  
>> part.
>> also had other reports pointing to that.  I aim to look into
>> this next week when i am back from EuroPython ...
>>
>> can you meanwhile post your Python version and attach the test
>> file that triggered the problems?
>>
>> best & thanks,
>>
>> holger
>>
>>
>> On Sat, Jul 12, 2008 at 10:50 +1200, Matthew Edwards wrote:
>>> Hi
>>>
>>> I'm running py 0.9.1 (from tarfile) on Windows XP. I've written a
>>> couple of simple tests, which are in a folder called test. Whenever I
>>> do "py.test --looponfailing test/" I get the following output:
>>>
>>>
>>> inserting into sys.path: C:\Program Files\Python\Lib\site-packages
>>> * opening PopenGateway:  C:\Program Files\Python\python.exe
>>> Traceback (most recent call last):
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\bin\win32\\..\py.test", line 4, in
>>> <module>
>>>     py.test.cmdline.main()
>>>   File "C:\Program Files\Python\Lib\site-packages\py\test\cmdline.py",
>>> line 15, in main
>>>     failures = session.main()
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 82,
>>> in main
>>>     failures = self.run_remote_session(failures)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 100,
>>> in run_remote_session
>>>
>>>     gw, topdir = self._initslavegateway()
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 97,
>>> in _initslavegateway
>>>     return py.execnet.PopenGateway(self.executable), topdir
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\register.py", line 66, in
>>> __init__
>>>     super(PopenGateway, self).__init__(cmd)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\register.py", line 55, in
>>> __init__
>>>     super(PopenCmdGateway, self).__init__(io=io)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\register.py", line 29, in
>>> __init__
>>>     self._remote_bootstrap_gateway(io)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\register.py", line 80, in
>>> _remote_bootstrap_gateway
>>>     super(PopenGateway, self)._remote_bootstrap_gateway(io, s)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\register.py", line 49, in
>>> _remote_bootstrap_gateway
>>>     io.write('%r\n' % source)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\inputoutput.py", line 95, in
>>> write
>>>     self.outfile.write(data)
>>> IOError: [Errno 22] Invalid argument
>>>
>>> I can run the tests without --looponfailing.
>>>
>>> Any help appreciated
>>> Matthew
>>> _______________________________________________
>>> py-dev mailing list
>>> py-dev at codespeak.net
>>> http://codespeak.net/mailman/listinfo/py-dev
>>>
>>
>> -- 
>> collaborative expert contracting: http://merlinux.eu
>> pylib py.test/greenlets/svn APIs: http://pylib.org
>> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>


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


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

From holger at merlinux.eu  Tue Jul 22 21:18:37 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Jul 2008 21:18:37 +0200
Subject: [py-dev] pytest -f fails on windows (without pypy-1.0.0
	in	pythonpath, another error)
In-Reply-To: <7be3f35d0807220915l24e4425an56a878fe99fa44c9@mail.gmail.com>
References: <7be3f35d0807220915l24e4425an56a878fe99fa44c9@mail.gmail.com>
Message-ID: <20080722191837.GK22324@trillke.net>

Hi Harald,

I don't see how this error is any different from the one before. 
pypy shouldn't matter at all for "py.test -f". 

In another mail (i assume you are following py-dev
currently) i tried to fix the "py.test -f" win32 problem. 
i just ported the fixes to svn/py/dist.  Could you 
do a re-install and see if things work for you now? 

cheers, 

holger

On Tue, Jul 22, 2008 at 18:15 +0200, Harald Armin Massa wrote:
> C:\ham\ibox25>pytest -f
> * opening PopenGateway:  C:\Python25\python.exe
> MASTER: initiated slave terminal session ->
> MASTER: send start info, topdir=C:\ham\ibox25
> Traceback (most recent call last):
>   File "C:\Python25\Scripts\\py.test", line 4, in <module>
>     py.test.cmdline.main()
>   File "C:\Python25\Lib\site-packages\py\test\cmdline.py", line 15, in main
>     failures = session.main()
>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 82, in m
> ain
>     failures = self.run_remote_session(failures)
>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 111, in
> run_remote_session
>     return channel.receive()
>   File "C:\Python25\Lib\site-packages\py\execnet\channel.py", line 175, in recei
> ve
>     raise self._getremoteerror() or EOFError()
> EOFError
> 
> -- 
> GHUM Harald Massa
> persuadere et programmare
> Harald Armin Massa
> Spielberger Stra?e 49
> 70435 Stuttgart
> 0173/9409607
> no fx, no carrier pidgeon
> -
> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

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

From holger at merlinux.eu  Wed Jul 23 08:27:51 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 08:27:51 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
Message-ID: <20080723062751.GM22324@trillke.net>

Hi folks,

yesterday, Harald asked me on #pylib regarding integration of
py.test with Scite and just now i replied to a similar 
issue that Osmo posted on the issue tracker.  See below. 

I'd like to ask here as well:  What would you like
for py.test's output in order for it to be most helpful
with your mode of testing and particularly integration 
with editors?   

You may also subscribe to 

    https://codespeak.net/issue/py-dev/issue57

if you want to follow the implementation of this feature. 

cheers, 

holger

P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
      If you have anything *now* is a good time to file. 

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

----- Forwarded message from holger krekel <hpk at trillke.net> -----

From: holger krekel <hpk at trillke.net>
To: Osmo Salomaa <py-dev-issue at codespeak.net>
Cc: hpk at trillke.net, otsaloma at cc.hut.fi
Subject: Re: [issue57] Emacs and py.test tracebacks
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
X-Spambayes-Classification: ham; 0.00

Hi Osmo, 

thanks for your report!  If you have the following test_file.py:

    def somefunc():
        assert 0

    def test_func():
        somefunc()

you would probably like to get 

    /full/path/to/test_file1.py:3

in a line somewhere in the long traceback for this 
failing test function, right?  

What do you think about always adding a "summary" at 
the end of a test run that looks like this? 

    /full/path/to/test_file1.py:3  AssertionError: 0 
    /full/path/to/test_file3.py:47  ValueError: 0 ...
    ...

Or, to ask more generally, what would be most helpful 
output for your mode of testing with emacs? 

holger

        
On Wed, Jul 23, 2008 at 04:35 +0000, Osmo Salomaa wrote:
> New submission from Osmo Salomaa <otsaloma at cc.hut.fi>:
> 
> Currently the filename and line numbers in py.test's long tracebacks are of form
> "[FILENAME:LINENO]". Emacs's compilation buffer does not understand that format.
> Changing it to form "FILENAME:LINENO:" (no brackets and a trailing colon) allows
> Emacs to parse that and render it as a clickable link. Emacs is able to parse
> the filenames and line numbers in the short tracebacks, but the links don't work
> because it would require the full filepath.
> 
> I suspect other editors may suffer similarly, because there is no easy way to
> know that the opening bracket is not a part of the filename.
> 
> Based on a quick look only a one line change to py/test/representation.py,
> method 'repr_failure_tblong' would be needed to fix the long tracebacks.
> 
> ----------
> effort: easy
> messages: 147
> nosy: hpk, otsaloma
> priority: wish
> release: ???
> status: unread
> title: Emacs and py.test tracebacks
> 
> _______________________________________________________
> py lib development tracker <py-dev-issue at codespeak.net>
> <https://codespeak.net/issue/py-dev/issue57>
> _______________________________________________________
> 

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


----- End forwarded message -----


From haraldarminmassa at gmail.com  Wed Jul 23 10:14:03 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Wed, 23 Jul 2008 10:14:03 +0200
Subject: [py-dev] pytest -r does not work ... even with pypy present
In-Reply-To: <20080722170846.GH22324@trillke.net>
References: <7be3f35d0807220845g4685f1f3r39599880c4914c31@mail.gmail.com>
	<20080722170846.GH22324@trillke.net>
Message-ID: <7be3f35d0807230114t4a9e2755h4de973751c86fabe@mail.gmail.com>

Holger,

> huah!  py.test should not require pypy here
> but use the "source.js" that comes with package.
> I just fixed this with r56717 in http://codespeak.net/svn/py/dist
>
> So "py.test -r" should work now, also does on my windows installation.
> that mode is quite experimental but i think it's a very useful
> frontend in principle.

It works with r56717. At least it one-shot-works, that is:

pytest -r <testobjekt> gives a browser with the used html-site.

great work, thanks!!!

##########
What would be even greater:

make pytest loop on one file / directory, allways putting out
test-results as HTML. Redoing all tests on file change.

THAT would give a really wonderfull testing system: a pytest-Server
scanning (or using win32 Directory Change notifcation) the relevant
project and putting out test-information to http ... have one screen
comitted to show test results, and hack right on.

Harald


-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!

From haraldarminmassa at gmail.com  Wed Jul 23 10:17:34 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Wed, 23 Jul 2008 10:17:34 +0200
Subject: [py-dev] pytest -f fails on windows (without pypy-1.0.0 in
	pythonpath, another error)
In-Reply-To: <20080722191837.GK22324@trillke.net>
References: <7be3f35d0807220915l24e4425an56a878fe99fa44c9@mail.gmail.com>
	<20080722191837.GK22324@trillke.net>
Message-ID: <7be3f35d0807230117l674a6e02q5e40f105749d4696@mail.gmail.com>

> I don't see how this error is any different from the one before.
> pypy shouldn't matter at all for "py.test -f".

correct. Only difference in errors:

with pypy installed and in python-path, py.test uses channel.py form
the pypy-distribution, without pypy installed (or not in python path),
py.test uses it's own "channel.py"

That maybe the same invitation to trouble than the shared library hell
in some operating systems.... that's why I point out this behaviour;
because getting different behaviours from a testing-system depending
on the libraries installed on the system is challenging :)

Thanks for looking over the errors & fixing py.test to work,

Harald



> On Tue, Jul 22, 2008 at 18:15 +0200, Harald Armin Massa wrote:
>> C:\ham\ibox25>pytest -f
>> * opening PopenGateway:  C:\Python25\python.exe
>> MASTER: initiated slave terminal session ->
>> MASTER: send start info, topdir=C:\ham\ibox25
>> Traceback (most recent call last):
>>   File "C:\Python25\Scripts\\py.test", line 4, in <module>
>>     py.test.cmdline.main()
>>   File "C:\Python25\Lib\site-packages\py\test\cmdline.py", line 15, in main
>>     failures = session.main()
>>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 82, in m
>> ain
>>     failures = self.run_remote_session(failures)
>>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 111, in
>> run_remote_session
>>     return channel.receive()
>>   File "C:\Python25\Lib\site-packages\py\execnet\channel.py", line 175, in recei
>> ve
>>     raise self._getremoteerror() or EOFError()
>> EOFError
>>
>> --
>> GHUM Harald Massa
>> persuadere et programmare
>> Harald Armin Massa
>> Spielberger Stra?e 49
>> 70435 Stuttgart
>> 0173/9409607
>> no fx, no carrier pidgeon
>> -
>> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>
>
> --
> collaborative expert contracting: http://merlinux.eu
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> pylib py.test/greenlets/svn APIs: http://pylib.org
>



-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!

From haraldarminmassa at gmail.com  Wed Jul 23 10:20:40 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Wed, 23 Jul 2008 10:20:40 +0200
Subject: [py-dev] oncoming 0.9.2 release
Message-ID: <7be3f35d0807230120y3cc20515x68ebfd7322a21bed@mail.gmail.com>

Whish-list:

pytest -e
pytest --testforever

includes --startsserver and --runbrowser, loops "forever" until
Ctrl+Break on the given file / directory / filtered files and
publishes results on Webport.
Bonus points for really showing a traffic light :)

Harald

-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!

From schmir at gmail.com  Wed Jul 23 12:19:12 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 23 Jul 2008 12:19:12 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080723062751.GM22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
Message-ID: <932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>

On Wed, Jul 23, 2008 at 8:27 AM, holger krekel <holger at merlinux.eu> wrote:
>
> P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
>      If you have anything *now* is a good time to file.

The ability to mark test cases as "expected failures" would be nice.

Regards,
- Ralf

From holger at merlinux.eu  Wed Jul 23 12:24:18 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 12:24:18 +0200
Subject: [py-dev] pytest -f fails on windows (without pypy-1.0.0
	in	pythonpath, another error)
In-Reply-To: <7be3f35d0807230117l674a6e02q5e40f105749d4696@mail.gmail.com>
References: <7be3f35d0807220915l24e4425an56a878fe99fa44c9@mail.gmail.com>
	<20080722191837.GK22324@trillke.net>
	<7be3f35d0807230117l674a6e02q5e40f105749d4696@mail.gmail.com>
Message-ID: <20080723102418.GN22324@trillke.net>

Hi Harald, 

On Wed, Jul 23, 2008 at 10:17 +0200, Harald Armin Massa wrote:
> > I don't see how this error is any different from the one before.
> > pypy shouldn't matter at all for "py.test -f".
> 
> correct. Only difference in errors:
> 
> with pypy installed and in python-path, py.test uses channel.py form
> the pypy-distribution, without pypy installed (or not in python path),
> py.test uses it's own "channel.py"

svn/pypy/dist/pypy has an svn:external sibling "py" lib at
svn/pypy/dist/py and if you put pypy/dist on PYTHONPATH 
then the py lib this py lib is used.  So you are still
using a py lib's channel, not a "pypy one" :) 

> That maybe the same invitation to trouble than the shared library hell
> in some operating systems.... that's why I point out this behaviour;
> because getting different behaviours from a testing-system depending
> on the libraries installed on the system is challenging :)

I consider it a relatively normal PYTHONPATH issue.  
 
> Thanks for looking over the errors & fixing py.test to work,

thanks for reporting/pushing! 

holger
 
> > On Tue, Jul 22, 2008 at 18:15 +0200, Harald Armin Massa wrote:
> >> C:\ham\ibox25>pytest -f
> >> * opening PopenGateway:  C:\Python25\python.exe
> >> MASTER: initiated slave terminal session ->
> >> MASTER: send start info, topdir=C:\ham\ibox25
> >> Traceback (most recent call last):
> >>   File "C:\Python25\Scripts\\py.test", line 4, in <module>
> >>     py.test.cmdline.main()
> >>   File "C:\Python25\Lib\site-packages\py\test\cmdline.py", line 15, in main
> >>     failures = session.main()
> >>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 82, in m
> >> ain
> >>     failures = self.run_remote_session(failures)
> >>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 111, in
> >> run_remote_session
> >>     return channel.receive()
> >>   File "C:\Python25\Lib\site-packages\py\execnet\channel.py", line 175, in recei
> >> ve
> >>     raise self._getremoteerror() or EOFError()
> >> EOFError
> >>
> >> --
> >> GHUM Harald Massa
> >> persuadere et programmare
> >> Harald Armin Massa
> >> Spielberger Stra?e 49
> >> 70435 Stuttgart
> >> 0173/9409607
> >> no fx, no carrier pidgeon
> >> -
> >> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
> >> _______________________________________________
> >> py-dev mailing list
> >> py-dev at codespeak.net
> >> http://codespeak.net/mailman/listinfo/py-dev
> >>
> >
> > --
> > collaborative expert contracting: http://merlinux.eu
> > PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> > pylib py.test/greenlets/svn APIs: http://pylib.org
> >
> 
> 
> 
> -- 
> GHUM Harald Massa
> persuadere et programmare
> Harald Armin Massa
> Spielberger Stra?e 49
> 70435 Stuttgart
> 0173/9409607
> no fx, no carrier pigeon
> -
> EuroPython 2009 will take place in Birmingham - Stay tuned!
> 

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

From johnny at johnnydebris.net  Wed Jul 23 12:26:43 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Wed, 23 Jul 2008 12:26:43 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
 tracebacks)
In-Reply-To: <20080723062751.GM22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
Message-ID: <48870763.1020107@johnnydebris.net>

holger krekel wrote:
> P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
>       If you have anything *now* is a good time to file. 
>
>   
I would really, really like to have py.path.svnwc.status() parse XML 
rather than text (using regexps) as it does now, to fix (e.g.?) problems 
with spaces in the username... I fiddle-fixed this in 0.9.1, but it 
turns out not to work in all cases, and obviously parsing XML is more 
solid. Should be relatively easy to fix, and I wouldn't mind doing it 
myself, I just didn't find time yet... :(

Cheers,

Guido

From holger at merlinux.eu  Wed Jul 23 12:41:32 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 12:41:32 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
Message-ID: <20080723104132.GO22324@trillke.net>

Hi Ralf, 

On Wed, Jul 23, 2008 at 12:19 +0200, Ralf Schmitt wrote:
> On Wed, Jul 23, 2008 at 8:27 AM, holger krekel <holger at merlinux.eu> wrote:
> >
> > P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
> >      If you have anything *now* is a good time to file.
> 
> The ability to mark test cases as "expected failures" would be nice.

Yes, i also want something where i can checkin tests 
that are marked as bugs and have some clever reporting
anhd command line options for this (at best even 
be able to have a link to an issue tracker). 

maybe: 

    @py.test.mark(bug=number or string, url=URL) 
    def test_something():
        ...

although i would like this to also work in setup_*
functions and in python 2.3 nicely, i think. 
I imagine such a decorator to just set attributes 
on the function, not provide a new function.
and the py.test machinery to recognize these 
attributes.  Makes sense? 

Not sure i'd like to consider this for 0.9.2 to be honest
which i rather want to be a bugfix release - at least
not to introduce new concepts.  But i am also heavily
working on a cleanup / refactoring branch which i 
consider the base for a 1.0 hopefully not too far
in the future. 

cheers, 

holger

From holger at merlinux.eu  Wed Jul 23 12:44:01 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 12:44:01 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <48870763.1020107@johnnydebris.net>
References: <20080723062751.GM22324@trillke.net>
	<48870763.1020107@johnnydebris.net>
Message-ID: <20080723104401.GP22324@trillke.net>

Hi Guido, 

On Wed, Jul 23, 2008 at 12:26 +0200, Guido Wesdorp wrote:
> holger krekel wrote:
> > P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
> >       If you have anything *now* is a good time to file. 
> >
> >   
> I would really, really like to have py.path.svnwc.status() parse XML 
> rather than text (using regexps) as it does now, to fix (e.g.?) problems 
> with spaces in the username... I fiddle-fixed this in 0.9.1, but it 
> turns out not to work in all cases, and obviously parsing XML is more 
> solid. Should be relatively easy to fix, and I wouldn't mind doing it 
> myself, I just didn't find time yet... :(

Makes sense to me, hope you do find the time! :) 

At the time when py.path.svn started there was not much --xml
support from svn.  As long as we are compatible to svn >=1.3 
we are fine, i think.  Would be nice if you go for that and indeed
shouldn't be hard and easy to test that the xml parsing is
right (easier than the current mess). 

cheers,

holger

From holger at merlinux.eu  Wed Jul 23 12:54:43 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 12:54:43 +0200
Subject: [py-dev] oncoming 0.9.2 release
In-Reply-To: <7be3f35d0807230120y3cc20515x68ebfd7322a21bed@mail.gmail.com>
References: <7be3f35d0807230120y3cc20515x68ebfd7322a21bed@mail.gmail.com>
Message-ID: <20080723105443.GQ22324@trillke.net>

Hi Harald, 

On Wed, Jul 23, 2008 at 10:20 +0200, Harald Armin Massa wrote:
> Whish-list:
> 
> pytest -e
> pytest --testforever
> 
> includes --startsserver and --runbrowser, loops "forever" until
> Ctrl+Break on the given file / directory / filtered files and
> publishes results on Webport.
> Bonus points for really showing a traffic light :)

:) 

This is nothing for 0.9.2, i am afraid.  Particularly 
since i am relatively clueless about the browser reporter
currently.  But if you are up to do a patch that does
what you suggest i'd consider it. 

sidenote: I promise to support anyone going for
a (new) nice AJAX frontend :)  

sidenote++: 
For 1.0 i am currently revamping distributed testing,
would like to have a native cross-platform testing 
mode - eventually i'd like this to be possible: 

    py.test --plat=win32,linux,osx --looponfailing --rep=browser 

although the "plat" option is probably rather for 1.1. 

For 0.9.2 i'd like to focus on integration issues with
editors, win32 and other fixes and packaging issues. 
plus small improvements :) 

holger

From schmir at gmail.com  Wed Jul 23 13:04:16 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 23 Jul 2008 13:04:16 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080723104132.GO22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
Message-ID: <932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>

On Wed, Jul 23, 2008 at 12:41 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Ralf,
>> The ability to mark test cases as "expected failures" would be nice.
>
> Yes, i also want something where i can checkin tests
> that are marked as bugs and have some clever reporting
> anhd command line options for this (at best even
> be able to have a link to an issue tracker).
>
> maybe:
>
>    @py.test.mark(bug=number or string, url=URL)
>    def test_something():
>        ...

I've written a quick hack (which doesn't integrate nicely with
py.test). It can be viewed here:
http://code.pediapress.com/hg/mwlib/file/b75d189a01a2/mwlib/xfail.py
It checks the functions docstring for a link to the issue tracker. I'm
not quite sure if you want to have that decorator take an issue
number/link. When you've fixed that bug, you'll remove the decorator
and loose that valuable information.

>
> although i would like this to also work in setup_*
> functions and in python 2.3 nicely, i think.
> I imagine such a decorator to just set attributes
> on the function, not provide a new function.
> and the py.test machinery to recognize these
> attributes.  Makes sense?

sounds good.

>
> Not sure i'd like to consider this for 0.9.2 to be honest
> which i rather want to be a bugfix release - at least

ok.

> not to introduce new concepts.  But i am also heavily
> working on a cleanup / refactoring branch which i
> consider the base for a 1.0 hopefully not too far
> in the future.

nice.
Is there a list of active branches? the last time I looked at the svn
repo, trunk looked very quiet (or I used a bad path).



Thinking about it I have maybe another issue for 0.9.2. When using easy_install
the greenlets module is not installed correctly. I haven't looked into
this (python setup.py install works). But I will probably have a look
at it in the next days....


Regards
- Ralf

From johnny at johnnydebris.net  Wed Jul 23 13:10:51 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Wed, 23 Jul 2008 13:10:51 +0200
Subject: [py-dev] last minute features for 0.9.2 (Re: py.test and
 editors (Re: [issue57] Emacs and py.test tracebacks))
In-Reply-To: <17CC2E6F-0578-437B-AA09-9A2CB3728E66@jasper.es>
References: <20080723062751.GM22324@trillke.net>
	<48870763.1020107@johnnydebris.net>
	<17CC2E6F-0578-437B-AA09-9A2CB3728E66@jasper.es>
Message-ID: <488711BB.8030705@johnnydebris.net>

Jasper Spaans wrote:
> Sounds like a welcome improvement as we're using that code and it 
> feels a bit icky right now; I can free some hours the coming days to 
> help implement/test that.
>
Jasper: I'll see you (in person) thursday, so let's set a date do do 
some pairing then...

Cheers,

Guido

From holger at merlinux.eu  Wed Jul 23 13:34:26 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 13:34:26 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
Message-ID: <20080723113426.GS22324@trillke.net>

Hi Ralf, 

On Wed, Jul 23, 2008 at 13:04 +0200, Ralf Schmitt wrote:
> On Wed, Jul 23, 2008 at 12:41 PM, holger krekel <holger at merlinux.eu> wrote:
> > Hi Ralf,
> >> The ability to mark test cases as "expected failures" would be nice.
> >
> > Yes, i also want something where i can checkin tests
> > that are marked as bugs and have some clever reporting
> > anhd command line options for this (at best even
> > be able to have a link to an issue tracker).
> >
> > maybe:
> >
> >    @py.test.mark(bug=number or string, url=URL)
> >    def test_something():
> >        ...
> 
> I've written a quick hack (which doesn't integrate nicely with
> py.test). It can be viewed here:
> http://code.pediapress.com/hg/mwlib/file/b75d189a01a2/mwlib/xfail.py
> It checks the functions docstring for a link to the issue tracker. I'm
> not quite sure if you want to have that decorator take an issue
> number/link. When you've fixed that bug, you'll remove the decorator
> and loose that valuable information.

I think it's fine to have the decorator mostly stay forever.  

I think that py.test should usually always run the 
"bug" test but report them specially (no tracebacks) 
if they fail and maybe 

    .........bb...................

for the progress bar etc.  However, py.test would not
complain if it passes.  Then, for example, 

    py.test --bugs=173,...,...

would run all tests that are marked with these bug numbers
and turn on full traceback reporting when they fail.  

There are also other things that i'd like to tell 
py.test about a test, e.g. having it run "boxed", 
i.e. isolated so that it can segfault without 
disrupting the testing process. 

> > although i would like this to also work in setup_*
> > functions and in python 2.3 nicely, i think.
> > I imagine such a decorator to just set attributes
> > on the function, not provide a new function.
> > and the py.test machinery to recognize these
> > attributes.  Makes sense?
> 
> sounds good.
> 
> >
> > Not sure i'd like to consider this for 0.9.2 to be honest
> > which i rather want to be a bugfix release - at least
> 
> ok.
> 
> > not to introduce new concepts.  But i am also heavily
> > working on a cleanup / refactoring branch which i
> > consider the base for a 1.0 hopefully not too far
> > in the future.
> 
> nice.
> Is there a list of active branches? the last time I looked at the svn
> repo, trunk looked very quiet (or I used a bad path).

I just removed some branches in svn/py/branch which i think were 
already merged.  py/trunk is mostly what is in 0.9.1 plus a
few more improvements (and hacks).  Active development i 
currently do in the event branch which i'd like to 
merge to trunk hopefully soon. 
 
> Thinking about it I have maybe another issue for 0.9.2. When using easy_install
> the greenlets module is not installed correctly. I haven't looked into
> this (python setup.py install works). But I will probably have a look
> at it in the next days....

cool.  You may just work in release/0.9.x or branch off from there. 
The current way of compiling c-extension modules is a hack IIRC ... 
mostly because i am a bit clueless on how to this correctly,
particularly for win32. 

best, 

holger

From schmir at gmail.com  Wed Jul 23 14:43:45 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 23 Jul 2008 14:43:45 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080723113426.GS22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
Message-ID: <932f8baf0807230543vbb52d86kf8c8a094d6d02474@mail.gmail.com>

On Wed, Jul 23, 2008 at 1:34 PM, holger krekel <holger at merlinux.eu> wrote:

> I think it's fine to have the decorator mostly stay forever.
>

It looks like you want that decorator to attach more information to
test functions.
In the case where you only want to mark a test as expected failure, I
think it should be removed.

> I think that py.test should usually always run the
> "bug" test but report them specially (no tracebacks)
> if they fail and maybe
>
>    .........bb...................
>
> for the progress bar etc.  However, py.test would not
> complain if it passes.  Then, for example,

-0 for not complaining when it passes
I don't like that idea, but I also currently don't have the time to
argue about it. twisted's trial raises an error for expected failures
that succeed.

>
>    py.test --bugs=173,...,...
>
> would run all tests that are marked with these bug numbers
> and turn on full traceback reporting when they fail.
>
> There are also other things that i'd like to tell
> py.test about a test, e.g. having it run "boxed",
> i.e. isolated so that it can segfault without
> disrupting the testing process.

I would have used that a few times in the past..but I can surely live
without such a feature.

>> Thinking about it I have maybe another issue for 0.9.2. When using easy_install
>> the greenlets module is not installed correctly. I haven't looked into
>> this (python setup.py install works). But I will probably have a look
>> at it in the next days....
>
> cool.  You may just work in release/0.9.x or branch off from there.
> The current way of compiling c-extension modules is a hack IIRC ...
> mostly because i am a bit clueless on how to this correctly,
> particularly for win32.

I thought the trick was that it automatically compiles the c modules
on demand when it is imported?

From holger at merlinux.eu  Wed Jul 23 14:52:22 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 14:52:22 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0807230543vbb52d86kf8c8a094d6d02474@mail.gmail.com>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
	<932f8baf0807230543vbb52d86kf8c8a094d6d02474@mail.gmail.com>
Message-ID: <20080723125222.GT22324@trillke.net>

Hi Ralf, 

On Wed, Jul 23, 2008 at 14:43 +0200, Ralf Schmitt wrote:
> On Wed, Jul 23, 2008 at 1:34 PM, holger krekel <holger at merlinux.eu> wrote:
> 
> > I think it's fine to have the decorator mostly stay forever.
> >
> 
> It looks like you want that decorator to attach more information to
> test functions.
> In the case where you only want to mark a test as expected failure, I
> think it should be removed.
> 
> > I think that py.test should usually always run the
> > "bug" test but report them specially (no tracebacks)
> > if they fail and maybe
> >
> >    .........bb...................
> >
> > for the progress bar etc.  However, py.test would not
> > complain if it passes.  Then, for example,
> 
> -0 for not complaining when it passes
> I don't like that idea, but I also currently don't have the time to
> argue about it. twisted's trial raises an error for expected failures
> that succeed.

The "not complaining" part is not essential to me. 
We'll find a good solution i am sure.  After all one 
could specify "fixed=True", "shouldfail=True" or whatever
once the basic machinery is there to satisfy use cases.

> >    py.test --bugs=173,...,...
> >
> > would run all tests that are marked with these bug numbers
> > and turn on full traceback reporting when they fail.
> >
> > There are also other things that i'd like to tell
> > py.test about a test, e.g. having it run "boxed",
> > i.e. isolated so that it can segfault without
> > disrupting the testing process.
> 
> I would have used that a few times in the past..but I can surely live
> without such a feature.

for large projects it could evolve as being really helpful,
particularly if you can also specify platforms. 
 
> >> Thinking about it I have maybe another issue for 0.9.2. When using easy_install
> >> the greenlets module is not installed correctly. I haven't looked into
> >> this (python setup.py install works). But I will probably have a look
> >> at it in the next days....
> >
> > cool.  You may just work in release/0.9.x or branch off from there.
> > The current way of compiling c-extension modules is a hack IIRC ...
> > mostly because i am a bit clueless on how to this correctly,
> > particularly for win32.
> 
> I thought the trick was that it automatically compiles the c modules
> on demand when it is imported?

yes - but this is not the right thing for packaged 
or setup.py installs.  One may not have write access 
to the installation path for starters.  Or no 
c-compiler is available on win32 etc. 

holger

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

From haraldarminmassa at gmail.com  Wed Jul 23 17:33:41 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Wed, 23 Jul 2008 17:33:41 +0200
Subject: [py-dev] allow installation on windows with not-admin account
Message-ID: <7be3f35d0807230833w7138fd38p7b03ce7fd9e8a987@mail.gmail.com>

Hello,

setup.py fails on windows with limited users because

k = _winreg.OpenKey(reg, key, 0, _winreg.KEY_WRITE)

is not allowed (raises windows error)

I suggest to patch with try, except within py\misc\_dist.py lines 94ff
as follows:


def addbindir2path():
    if sys.platform != 'win32' or not winextensions:
        return

    # Add py/bin to PATH environment variable
    bindir = os.path.join(sysconfig.get_python_lib(), "py", "bin", "win32")
    reg = _winreg.ConnectRegistry(None, _winreg.HKEY_LOCAL_MACHINE)
    key = r"SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
    path = get_registry_value(reg, key, "Path")
    path += ";" + bindir
    print "Setting PATH to:", path
    try:
        set_registry_value(reg, key, "Path", path)
    except WindowsError:
        print "could not write new path to registry. permissions?"
        return
    #print "Current PATH is:", get_registry_value(reg, key, "Path")

    # Propagate changes throughout the system
    win32gui.SendMessageTimeout(win32con.HWND_BROADCAST,
        win32con.WM_SETTINGCHANGE, 0, "Environment",
        win32con.SMTO_ABORTIFHUNG, 5000)

    # Propagate changes to current command prompt
    os.system("set PATH=%s" % path)


Harald

-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!

From holger at merlinux.eu  Fri Jul 25 11:22:04 2008
From: holger at merlinux.eu (holger krekel)
Date: Fri, 25 Jul 2008 11:22:04 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <20080723062751.GM22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
Message-ID: <20080725092204.GE22324@trillke.net>

Hi again,

so in the course of issue57 i changed the output format 
to integrate better with editors.  The 

    http://codespeak.net/svn/py/release/0.9.x 

and dist branches contain the changes. 

holger


On Wed, Jul 23, 2008 at 08:27 +0200, holger krekel wrote:
> Hi folks,
> 
> yesterday, Harald asked me on #pylib regarding integration of
> py.test with Scite and just now i replied to a similar 
> issue that Osmo posted on the issue tracker.  See below. 
> 
> I'd like to ask here as well:  What would you like
> for py.test's output in order for it to be most helpful
> with your mode of testing and particularly integration 
> with editors?   
> 
> You may also subscribe to 
> 
>     https://codespeak.net/issue/py-dev/issue57
> 
> if you want to follow the implementation of this feature. 
> 
> cheers, 
> 
> holger
> 
> P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
>       If you have anything *now* is a good time to file. 
> 
> -- 
> collaborative expert contracting: http://merlinux.eu 
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
> pylib py.test/greenlets/svn APIs: http://pylib.org 
> 
> ----- Forwarded message from holger krekel <hpk at trillke.net> -----
> 
> From: holger krekel <hpk at trillke.net>
> To: Osmo Salomaa <py-dev-issue at codespeak.net>
> Cc: hpk at trillke.net, otsaloma at cc.hut.fi
> Subject: Re: [issue57] Emacs and py.test tracebacks
> User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
> X-Spambayes-Classification: ham; 0.00
> 
> Hi Osmo, 
> 
> thanks for your report!  If you have the following test_file.py:
> 
>     def somefunc():
>         assert 0
> 
>     def test_func():
>         somefunc()
> 
> you would probably like to get 
> 
>     /full/path/to/test_file1.py:3
> 
> in a line somewhere in the long traceback for this 
> failing test function, right?  
> 
> What do you think about always adding a "summary" at 
> the end of a test run that looks like this? 
> 
>     /full/path/to/test_file1.py:3  AssertionError: 0 
>     /full/path/to/test_file3.py:47  ValueError: 0 ...
>     ...
> 
> Or, to ask more generally, what would be most helpful 
> output for your mode of testing with emacs? 
> 
> holger
> 
>         
> On Wed, Jul 23, 2008 at 04:35 +0000, Osmo Salomaa wrote:
> > New submission from Osmo Salomaa <otsaloma at cc.hut.fi>:
> > 
> > Currently the filename and line numbers in py.test's long tracebacks are of form
> > "[FILENAME:LINENO]". Emacs's compilation buffer does not understand that format.
> > Changing it to form "FILENAME:LINENO:" (no brackets and a trailing colon) allows
> > Emacs to parse that and render it as a clickable link. Emacs is able to parse
> > the filenames and line numbers in the short tracebacks, but the links don't work
> > because it would require the full filepath.
> > 
> > I suspect other editors may suffer similarly, because there is no easy way to
> > know that the opening bracket is not a part of the filename.
> > 
> > Based on a quick look only a one line change to py/test/representation.py,
> > method 'repr_failure_tblong' would be needed to fix the long tracebacks.
> > 
> > ----------
> > effort: easy
> > messages: 147
> > nosy: hpk, otsaloma
> > priority: wish
> > release: ???
> > status: unread
> > title: Emacs and py.test tracebacks
> > 
> > _______________________________________________________
> > py lib development tracker <py-dev-issue at codespeak.net>
> > <https://codespeak.net/issue/py-dev/issue57>
> > _______________________________________________________
> > 
> 
> -- 
> collaborative expert contracting: http://merlinux.eu 
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
> pylib py.test/greenlets/svn APIs: http://pylib.org 
> 
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

From johnny at johnnydebris.net  Wed Jul 30 12:15:56 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Wed, 30 Jul 2008 12:15:56 +0200
Subject: [py-dev] svn st --xml support for py.path - progress
Message-ID: <48903F5C.5010306@johnnydebris.net>

Hi!

Yesterday I had some time to spare so decided to work on using the XML 
output of svn st rather than the text to get py.path.svnwc.status() 
reports. After some refactoring, adding some tests and battling the test 
code a bit, I ended up with something that at least satisfies the tests 
- they all work with the new code, using the old code as fallback if the 
--xml switch gets refused.

I did this on a branch, as at first it seemed like I had to do a lot of 
refactoring of the tests (which I ended up mostly rolling back). The URL 
of this branch is:

https://codespeak.net/svn/py/branch/guido-svnwc-xml-status

Unfortunately I didn't find the time to test on any platform other than 
Linux, using SVN v. 1.3. Therefore I think the code, in its current 
status, shouldn't be merged into the next release branch, or at least 
not without more testing (this also because I have the feeling a lot of 
edge cases aren't covered in the tests). However, what is there should 
be feature-complete...

If people feel like testing, I'd greatly appreciate it... If not, I'll 
do it the first opportunity I have. I think the most important questions 
now are if it works on Windows, and on SVN versions besides 1.3. If 
that's done I think it can be merged into trunk and release branch.

Cheers,

Guido

From holger at merlinux.eu  Wed Jul 30 20:55:00 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 30 Jul 2008 20:55:00 +0200
Subject: [py-dev] svn st --xml support for py.path - progress
In-Reply-To: <48903F5C.5010306@johnnydebris.net>
References: <48903F5C.5010306@johnnydebris.net>
Message-ID: <20080730185500.GM9619@trillke.net>

Hi Guido, 

On Wed, Jul 30, 2008 at 12:15 +0200, Guido Wesdorp wrote:
> Yesterday I had some time to spare so decided to work on using the XML 
> output of svn st rather than the text to get py.path.svnwc.status() 
> reports. After some refactoring, adding some tests and battling the test 
> code a bit, I ended up with something that at least satisfies the tests 
> - they all work with the new code, using the old code as fallback if the 
> --xml switch gets refused.
> 
> I did this on a branch, as at first it seemed like I had to do a lot of 
> refactoring of the tests (which I ended up mostly rolling back). The URL 
> of this branch is:
> 
> https://codespeak.net/svn/py/branch/guido-svnwc-xml-status
>
> Unfortunately I didn't find the time to test on any platform other than 
> Linux, using SVN v. 1.3. Therefore I think the code, in its current 
> status, shouldn't be merged into the next release branch, or at least 
> not without more testing (this also because I have the feeling a lot of 
> edge cases aren't covered in the tests). However, what is there should 
> be feature-complete...

first feedback (i am not much working currently, am ill/feverish):
tests pass for me on Win XP with svn 1.4.4.  They take 38
seconds instead of 24 on dist, though. 

cheers,

holger

From johnny at johnnydebris.net  Thu Jul 31 08:30:02 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Thu, 31 Jul 2008 08:30:02 +0200
Subject: [py-dev] svn st --xml support for py.path - progress
In-Reply-To: <20080730185500.GM9619@trillke.net>
References: <48903F5C.5010306@johnnydebris.net>
	<20080730185500.GM9619@trillke.net>
Message-ID: <48915BEA.5090409@johnnydebris.net>

holger krekel wrote:
> first feedback (i am not much working currently, am ill/feverish):
> tests pass for me on Win XP with svn 1.4.4.  They take 38
> seconds instead of 24 on dist, though. 
>
>   
That's rather strange, as I (unexpectedly) didn't touch the test code 
much... But I'll investigate.

Cheers,

Guido

From schmir at gmail.com  Mon Aug  4 10:20:21 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Mon, 4 Aug 2008 10:20:21 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080723113426.GS22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
Message-ID: <932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>

On Wed, Jul 23, 2008 at 1:34 PM, holger krekel <holger at merlinux.eu> wrote:
>> Thinking about it I have maybe another issue for 0.9.2. When using easy_install
>> the greenlets module is not installed correctly. I haven't looked into
>> this (python setup.py install works). But I will probably have a look
>> at it in the next days....
>
> cool.  You may just work in release/0.9.x or branch off from there.
> The current way of compiling c-extension modules is a hack IIRC ...
> mostly because i am a bit clueless on how to this correctly,
> particularly for win32.
>

Hi Holger,

I took the time to look at it. It looks like a packaging issue.
The archive found on cheeseshop (
http://pypi.python.org/packages/source/p/py/py-0.9.1.tar.gz#md5=daab8d9a814eab31809d973370d23600)
does not even contain the
c-extension directory.

easy_install -f http://codespeak.net/py/dist/download.html works.

Regards,
- Ralf

From holger at merlinux.eu  Mon Aug  4 10:41:32 2008
From: holger at merlinux.eu (holger krekel)
Date: Mon, 4 Aug 2008 10:41:32 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
	<932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>
Message-ID: <20080804084131.GL9619@trillke.net>

Hi Ralf, 

On Mon, Aug 04, 2008 at 10:20 +0200, Ralf Schmitt wrote:
> On Wed, Jul 23, 2008 at 1:34 PM, holger krekel <holger at merlinux.eu> wrote:
> >> Thinking about it I have maybe another issue for 0.9.2. When using easy_install
> >> the greenlets module is not installed correctly. I haven't looked into
> >> this (python setup.py install works). But I will probably have a look
> >> at it in the next days....
> >
> > cool.  You may just work in release/0.9.x or branch off from there.
> > The current way of compiling c-extension modules is a hack IIRC ...
> > mostly because i am a bit clueless on how to this correctly,
> > particularly for win32.
> >
> 
> Hi Holger,
> 
> I took the time to look at it. It looks like a packaging issue.
> The archive found on cheeseshop (
> http://pypi.python.org/packages/source/p/py/py-0.9.1.tar.gz#md5=daab8d9a814eab31809d973370d23600)
> does not even contain the
> c-extension directory.
> 
> easy_install -f http://codespeak.net/py/dist/download.html works.

ok, but this requires a C-compiler on the client side. 
The thing i don't know much about is how to best provide eggs 
with pre-compiled c-extensions. 

best, 
holger

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

From schmir at gmail.com  Mon Aug  4 11:01:40 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Mon, 4 Aug 2008 11:01:40 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080804084131.GL9619@trillke.net>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
	<932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>
	<20080804084131.GL9619@trillke.net>
Message-ID: <932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>

On Mon, Aug 4, 2008 at 10:41 AM, holger krekel <holger at merlinux.eu> wrote:

>
> ok, but this requires a C-compiler on the client side.
> The thing i don't know much about is how to best provide eggs
> with pre-compiled c-extensions.
>

ahh. ok. But you really shouldn't remove the c code...
python setup.py bdist_wininst will create a binary installer suitable
for windows.
In case you use setuptools python setup.py bdist_egg would build an egg.
But I guess then the problem is that your setup.py does not even
compile the c-extensions when it's run?
What about removing some magic and using a standard setup.py?

Regards,
- Ralf

From holger at merlinux.eu  Mon Aug  4 12:02:46 2008
From: holger at merlinux.eu (holger krekel)
Date: Mon, 4 Aug 2008 12:02:46 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
	<932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>
	<20080804084131.GL9619@trillke.net>
	<932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>
Message-ID: <20080804100246.GN9619@trillke.net>

Hi Ralf, 

On Mon, Aug 04, 2008 at 11:01 +0200, Ralf Schmitt wrote:
> On Mon, Aug 4, 2008 at 10:41 AM, holger krekel <holger at merlinux.eu> wrote:
> 
> >
> > ok, but this requires a C-compiler on the client side.
> > The thing i don't know much about is how to best provide eggs
> > with pre-compiled c-extensions.
> >
> 
> ahh. ok. But you really shouldn't remove the c code...
> python setup.py bdist_wininst will create a binary installer suitable
> for windows.
> In case you use setuptools python setup.py bdist_egg would build an egg.
> But I guess then the problem is that your setup.py does not even
> compile the c-extensions when it's run?
> What about removing some magic and using a standard setup.py?

that's a good idea, i think.  

Actually i'd like to have a (generated or manually written for
now) setup.py that plays along nicely with setuptools.  
Maybe it'S good if it also works without setuptools?

What do you think about starting a branch (based on release/0.9.x)
to get it towards such a state?   

cheers,

holger

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

From schmir at gmail.com  Mon Aug  4 14:57:14 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Mon, 4 Aug 2008 14:57:14 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080804100246.GN9619@trillke.net>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
	<932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>
	<20080804084131.GL9619@trillke.net>
	<932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>
	<20080804100246.GN9619@trillke.net>
Message-ID: <932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>

On Mon, Aug 4, 2008 at 12:02 PM, holger krekel <holger at merlinux.eu> wrote:

>> What about removing some magic and using a standard setup.py?
>
> that's a good idea, i think.
>
> Actually i'd like to have a (generated or manually written for
> now) setup.py that plays along nicely with setuptools.
> Maybe it'S good if it also works without setuptools?

I would rather use setuptools. You could remove the whole py/bin/win32
directory as setuptools will create an .exe for each script.
It's also easier to include data files, and makes development easier
by being able to install the package in-place (python setup.py
develop).

However, it's also possible to create a standard distutils setup.py,
which works with setuptools easy_install (you basically already have
it) and which allows building a binary package for windows.

>
> What do you think about starting a branch (based on release/0.9.x)
> to get it towards such a state?

Yes, why not. You want me to donate some spare time to work on it?

What do you think about distributing the greenlet module as it's own package?
Do you know about http://pypi.python.org/pypi/greenlet/?
(I've recently tried the eventlet library, which specifies the above
as a dependency).

Regards,
- Ralf

From holger at merlinux.eu  Mon Aug  4 15:48:32 2008
From: holger at merlinux.eu (holger krekel)
Date: Mon, 4 Aug 2008 15:48:32 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
	<932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>
	<20080804084131.GL9619@trillke.net>
	<932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>
	<20080804100246.GN9619@trillke.net>
	<932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>
Message-ID: <20080804134832.GO9619@trillke.net>

Hi Ralf, 

On Mon, Aug 04, 2008 at 14:57 +0200, Ralf Schmitt wrote:
> On Mon, Aug 4, 2008 at 12:02 PM, holger krekel <holger at merlinux.eu> wrote:
> 
> >> What about removing some magic and using a standard setup.py?
> >
> > that's a good idea, i think.
> >
> > Actually i'd like to have a (generated or manually written for
> > now) setup.py that plays along nicely with setuptools.
> > Maybe it'S good if it also works without setuptools?
> 
> I would rather use setuptools. You could remove the whole py/bin/win32
> directory as setuptools will create an .exe for each script.
> It's also easier to include data files, and makes development easier
> by being able to install the package in-place (python setup.py
> develop).
> 
> However, it's also possible to create a standard distutils setup.py,
> which works with setuptools easy_install (you basically already have
> it) and which allows building a binary package for windows.

I don't have a strong opinion on this.  But for python 2.3 and
2.4 i guess it's somewhat nice to be able to type "python setup.py install" 
and have it work indepedently from the question if 
setuptools is installed.  

> > What do you think about starting a branch (based on release/0.9.x)
> > to get it towards such a state?
> 
> Yes, why not. You want me to donate some spare time to work on it?

would be nice!  i'd also contribute, of course.
 
> What do you think about distributing the greenlet module as it's own package?
> Do you know about http://pypi.python.org/pypi/greenlet/?

yes. is it actively maintained, though? 

> (I've recently tried the eventlet library, which specifies the above
> as a dependency).

originally the greenlet lib was moved into the py lib 
to ease maintenance and because it was used in PyPy and
we didn't want to add dependencies there.  

Today, I'd be fine both ways - for 0.9.2 i guess 
greenlets should still be part of the py lib, though. 

cheers, 

holger

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

From schmir at gmail.com  Mon Aug  4 16:11:38 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Mon, 4 Aug 2008 16:11:38 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080804134832.GO9619@trillke.net>
References: <20080723062751.GM22324@trillke.net>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
	<932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>
	<20080804084131.GL9619@trillke.net>
	<932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>
	<20080804100246.GN9619@trillke.net>
	<932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>
	<20080804134832.GO9619@trillke.net>
Message-ID: <932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>

On Mon, Aug 4, 2008 at 3:48 PM, holger krekel <holger at merlinux.eu> wrote:
> I don't have a strong opinion on this.  But for python 2.3 and
> 2.4 i guess it's somewhat nice to be able to type "python setup.py install"
> and have it work indepedently from the question if
> setuptools is installed.
>

setuptools enabled packages come with a short bootstrap module which
does install setuptools in case it is not installed. This should also
work with python 2.3.
(I think you will also need vs 6.0 instead of vs 2003 to build
extensions for python 2.3 on windows)

>
>> What do you think about distributing the greenlet module as it's own package?
>> Do you know about http://pypi.python.org/pypi/greenlet/?
>
> yes. is it actively maintained, though?
>

I don't think so..but I could be wrong, pypi unfortunately does not
show the release date.

>
> originally the greenlet lib was moved into the py lib
> to ease maintenance and because it was used in PyPy and
> we didn't want to add dependencies there.
>
> Today, I'd be fine both ways - for 0.9.2 i guess
> greenlets should still be part of the py lib, though.
>

ok. I'll try to implement a setuptools based setup.py then.

Regards,
- Ralf

From johnny at johnnydebris.net  Thu Aug  7 22:39:08 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Thu, 07 Aug 2008 22:39:08 +0200
Subject: [py-dev] svn st --xml support for py.path - progress
In-Reply-To: <48903F5C.5010306@johnnydebris.net>
References: <48903F5C.5010306@johnnydebris.net>
Message-ID: <489B5D6C.8000402@johnnydebris.net>

Guido Wesdorp wrote:
> Unfortunately I didn't find the time to test on any platform other than 
> Linux, using SVN v. 1.3.
The tests seem to run successfully on:

Linux with SVN 1.3 and 1.4
Mac OS-X with SVN 1.4
Windows XP with SVN 1.4

Also tested SVN 1.5 on Windows XP, which fails, but that also happens 
with trunk...

The only thing I'm not sure how to handle, and which is currently not 
supported, is the 'kindmismatch' attribute name. There doesn't seem to 
be a test for this, and I'm not even sure how to produce a report with 
such an attribute... Apart from that, I think the branch can be merged. 
(Note that I left in the old code for when the --xml switch fails, this 
should be removed when 1.2 support is dropped.)

Cheers,

Guido

From holger at merlinux.eu  Fri Aug  8 08:10:12 2008
From: holger at merlinux.eu (holger krekel)
Date: Fri, 8 Aug 2008 08:10:12 +0200
Subject: [py-dev] svn st --xml support for py.path - progress
In-Reply-To: <489B5D6C.8000402@johnnydebris.net>
References: <48903F5C.5010306@johnnydebris.net>
	<489B5D6C.8000402@johnnydebris.net>
Message-ID: <20080808061012.GU9619@trillke.net>

Hi Guido, 

On Thu, Aug 07, 2008 at 22:39 +0200, Guido Wesdorp wrote:
> Guido Wesdorp wrote:
> > Unfortunately I didn't find the time to test on any platform other than 
> > Linux, using SVN v. 1.3.
> The tests seem to run successfully on:
> 
> Linux with SVN 1.3 and 1.4
> Mac OS-X with SVN 1.4
> Windows XP with SVN 1.4

same here, good. 

> Also tested SVN 1.5 on Windows XP, which fails, but that also happens 
> with trunk...

could you attach a textual log of the failures? 
 
> The only thing I'm not sure how to handle, and which is currently not 
> supported, is the 'kindmismatch' attribute name. There doesn't seem to 
> be a test for this, and I'm not even sure how to produce a report with 
> such an attribute... Apart from that, I think the branch can be merged. 
> (Note that I left in the old code for when the --xml switch fails, this 
> should be removed when 1.2 support is dropped.)

did you get to check the degraded test speed? 

cheers, 
holger

From johnny at johnnydebris.net  Fri Aug  8 09:21:09 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Fri, 08 Aug 2008 09:21:09 +0200
Subject: [py-dev] svn st --xml support for py.path - progress
In-Reply-To: <20080808061012.GU9619@trillke.net>
References: <48903F5C.5010306@johnnydebris.net>
	<489B5D6C.8000402@johnnydebris.net>
	<20080808061012.GU9619@trillke.net>
Message-ID: <489BF3E5.70205@johnnydebris.net>

holger krekel wrote:
>> Also tested SVN 1.5 on Windows XP, which fails, but that also happens 
>> with trunk...
>>     
>
> could you attach a textual log of the failures? 
>   
Hrmph, not easily, but I'll do my best (nice to work on a platform where 
e.g. copy/paste from a console doesn't work)...

> did you get to check the degraded test speed? 
>
>   
Ah, right, did that just now... I fear the problem is that SVN 
interaction is just slow, there's a test (test_status_conflict) that 
takes about 7 seconds to run on my machine, while I don't think it does 
anything unexpected... It just creates a second wc, checks out the repo, 
does some writes and commits and checks for conflicts, which I guess is 
what it _should_ do. I already changed it so that it doesn't build its 
own repo anymore, but still it takes a _long_ time to run - i fear the 
problem is just SVN. :(

Cheers,

Guido

From monopocalypse+py-dev at gmail.com  Sun Aug 10 22:17:59 2008
From: monopocalypse+py-dev at gmail.com (Matthew Edwards)
Date: Mon, 11 Aug 2008 08:17:59 +1200
Subject: [py-dev] Exceptions in setup/teardown hooks
Message-ID: <4025a36d0808101317y594c42ceq54c476ad13a303cb@mail.gmail.com>

Hi,

I've got some tests for a module which manages log files. The setup_class
and teardown_class functions create and delete a directory for them, and the
teardown_method function deletes the individual files based on a list. When
a test fails, it can leave files which aren't on the list, so don't get
deleted in teardown_method, which makes teardown_class choke on os.rmdir
(because the directory is not empty). While I do need to know if there are
files left over, the problem is that when an exception occurs in a hook, it
shows a traceback for that only, and not the actual test failure, so I can't
tell what failed.

Am I just doing this wrong, or is this a bit of a bug? I would prefer an
exception in [setup|teardown]_method to fail that method, and an exception
in [setup|teardown]_class to fail all the tests in that class, and if an
exception is raised in a test and the following hook, tracebacks for both
should be displayed.

As an aside, stdout capture doesn't work particularly well from the hooks
either.

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

From nshepperd at gmail.com  Mon Aug 11 08:36:13 2008
From: nshepperd at gmail.com (Neil Shepperd)
Date: Mon, 11 Aug 2008 16:36:13 +1000
Subject: [py-dev] Exceptions in setup/teardown hooks
In-Reply-To: <4025a36d0808101317y594c42ceq54c476ad13a303cb@mail.gmail.com>
References: <4025a36d0808101317y594c42ceq54c476ad13a303cb@mail.gmail.com>
Message-ID: <1218436573.6463.14.camel@neil>

On Mon, 2008-08-11 at 08:17 +1200, Matthew Edwards wrote:
> Hi,
> 
> I've got some tests for a module which manages log files. The
> setup_class and teardown_class functions create and delete a directory
> for them, and the teardown_method function deletes the individual
> files based on a list. When a test fails, it can leave files which
> aren't on the list, so don't get deleted in teardown_method, which
> makes teardown_class choke on os.rmdir (because the directory is not
> empty). While I do need to know if there are files left over, the
> problem is that when an exception occurs in a hook, it shows a
> traceback for that only, and not the actual test failure, so I can't
> tell what failed.
If having no files left over is necessary for the test to pass,
that should be part of the test. You should probably use rmtree
in the hook, as hooks are not tests, and must always work - independent
of whether the test itself passes.
> 
> Am I just doing this wrong, or is this a bit of a bug? I would prefer
> an exception in [setup|teardown]_method to fail that method, and an
> exception in [setup|teardown]_class to fail all the tests in that
> class
May be a bad idea. IMHO setup/teardown should do just what they're
called - setup and teardown an environment for tests to run in. If
an exception occurs in [setup|teardown]_* it should be because your
setup/teardown code is broken. Mixing up setup/teardown with tests
themselves seems like a mistake to me.

Neil Shepperd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://codespeak.net/pipermail/py-dev/attachments/20080811/8c05d677/attachment-0001.pgp 

From monopocalypse+py-dev at gmail.com  Mon Aug 11 08:44:41 2008
From: monopocalypse+py-dev at gmail.com (Matthew Edwards)
Date: Mon, 11 Aug 2008 18:44:41 +1200
Subject: [py-dev] Exceptions in setup/teardown hooks
In-Reply-To: <1218436423.6463.11.camel@neil>
References: <4025a36d0808101317y594c42ceq54c476ad13a303cb@mail.gmail.com>
	<1218436423.6463.11.camel@neil>
Message-ID: <4025a36d0808102344i18f24538h22fc549436037aff@mail.gmail.com>

Thanks, I'll try that. It's just that it's likely I'll end up moving stuff
from [setup|teardown]_* into other functions which I call manually (or
possibly magically) before and after each test, which seems a bit
counterproductive.

Matthew

On Mon, Aug 11, 2008 at 6:33 PM, Neil Shepperd <nshepperd at gmail.com> wrote:

> On Mon, 2008-08-11 at 08:17 +1200, Matthew Edwards wrote:
> > Hi,
> >
> > I've got some tests for a module which manages log files. The
> > setup_class and teardown_class functions create and delete a directory
> > for them, and the teardown_method function deletes the individual
> > files based on a list. When a test fails, it can leave files which
> > aren't on the list, so don't get deleted in teardown_method, which
> > makes teardown_class choke on os.rmdir (because the directory is not
> > empty). While I do need to know if there are files left over, the
> > problem is that when an exception occurs in a hook, it shows a
> > traceback for that only, and not the actual test failure, so I can't
> > tell what failed.
> If having no files left over is necessary for the test to pass,
> that should be part of the test. You should probably use rmtree
> in the hook, as hooks are not tests, and must always work - independent
> of whether the test itself passes.
> >
> > Am I just doing this wrong, or is this a bit of a bug? I would prefer
> > an exception in [setup|teardown]_method to fail that method, and an
> > exception in [setup|teardown]_class to fail all the tests in that
> > class
> May be a bad idea. IMHO setup/teardown should do just what they're
> called - setup and teardown an environment for tests to run in. If
> an exception occurs in [setup|teardown]_* it should be because your
> setup/teardown code is broken. Mixing up setup/teardown with tests
> themselves seems like a mistake to me.
>
> Neil Shepperd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20080811/28f855a1/attachment.htm 

From holger at merlinux.eu  Mon Aug 11 09:10:50 2008
From: holger at merlinux.eu (holger krekel)
Date: Mon, 11 Aug 2008 09:10:50 +0200
Subject: [py-dev] Exceptions in setup/teardown hooks
In-Reply-To: <4025a36d0808101317y594c42ceq54c476ad13a303cb@mail.gmail.com>
References: <4025a36d0808101317y594c42ceq54c476ad13a303cb@mail.gmail.com>
Message-ID: <20080811071050.GC9619@trillke.net>

Hi Matthew, 

On Mon, Aug 11, 2008 at 08:17 +1200, Matthew Edwards wrote:
> Hi,
> 
> I've got some tests for a module which manages log files. The setup_class
> and teardown_class functions create and delete a directory for them, and the
> teardown_method function deletes the individual files based on a list. When
> a test fails, it can leave files which aren't on the list, so don't get
> deleted in teardown_method, which makes teardown_class choke on os.rmdir
> (because the directory is not empty). While I do need to know if there are
> files left over, the problem is that when an exception occurs in a hook, it
> shows a traceback for that only, and not the actual test failure, so I can't
> tell what failed.

Hum, I think failing setup/teardown methods could use more helpful
debug info.  This should be better on trunk soon (after i
merge the branch i am currently working on).  

Otherwise i agree with Neil.  setup/teardowns should not
contain test code by design. In practise they often 
call into application code that may fail and there is
nothing wrong with being more helpful about this.  

Concretely, I think a "self.assert_nofilesleft()" at the end
of the tests in question is fine and makes it obvious what is
expected program behaviour. 

> Am I just doing this wrong, or is this a bit of a bug? I would prefer an
> exception in [setup|teardown]_method to fail that method, and an exception
> in [setup|teardown]_class to fail all the tests in that class, and if an
> exception is raised in a test and the following hook, tracebacks for both
> should be displayed.

I agree that teardown_method/teardown_function reporting should 
closely relate to the test object.  I don't think that 
teardown_class should fail all tests retroactively - they were
already reported as success.  Again, it should indeed get
easier to see what test class failed. 

> As an aside, stdout capture doesn't work particularly well from the hooks
> either.

is better already. 

cheers,

holger

From holger at merlinux.eu  Tue Aug 12 21:16:31 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 12 Aug 2008 21:16:31 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>
References: <20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
	<932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>
	<20080804084131.GL9619@trillke.net>
	<932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>
	<20080804100246.GN9619@trillke.net>
	<932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>
	<20080804134832.GO9619@trillke.net>
	<932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>
Message-ID: <20080812191631.GH9619@trillke.net>

Hi Ralf, 

On Mon, Aug 04, 2008 at 16:11 +0200, Ralf Schmitt wrote:
> On Mon, Aug 4, 2008 at 3:48 PM, holger krekel <holger at merlinux.eu> wrote:
> > I don't have a strong opinion on this.  But for python 2.3 and
> > 2.4 i guess it's somewhat nice to be able to type "python setup.py install"
> > and have it work indepedently from the question if
> > setuptools is installed.
> >
> 
> setuptools enabled packages come with a short bootstrap module which
> does install setuptools in case it is not installed. This should also
> work with python 2.3.
> (I think you will also need vs 6.0 instead of vs 2003 to build
> extensions for python 2.3 on windows)

ok.  if we want to ship with a pre-compiled greenlet module 
we would need to distribute per-python versions, right? 
If we can't manage this ourselves then i hope we can 
find people to prepare binary eggs. 

> > originally the greenlet lib was moved into the py lib
> > to ease maintenance and because it was used in PyPy and
> > we didn't want to add dependencies there.
> >
> > Today, I'd be fine both ways - for 0.9.2 i guess
> > greenlets should still be part of the py lib, though.
> >
> 
> ok. I'll try to implement a setuptools based setup.py then.

any chances you'll get to that this week?  I think i'd
like to get the 0.9.2 release out the coming weekend. 

cheers, 

holger

From schmir at gmail.com  Wed Aug 13 00:13:02 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 13 Aug 2008 00:13:02 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080812191631.GH9619@trillke.net>
References: <20080723104132.GO22324@trillke.net>
	<20080723113426.GS22324@trillke.net>
	<932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>
	<20080804084131.GL9619@trillke.net>
	<932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>
	<20080804100246.GN9619@trillke.net>
	<932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>
	<20080804134832.GO9619@trillke.net>
	<932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>
	<20080812191631.GH9619@trillke.net>
Message-ID: <932f8baf0808121513t677faa05yca90262a02f1b982@mail.gmail.com>

On Tue, Aug 12, 2008 at 9:16 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Ralf,
>
> On Mon, Aug 04, 2008 at 16:11 +0200, Ralf Schmitt wrote:
>> On Mon, Aug 4, 2008 at 3:48 PM, holger krekel <holger at merlinux.eu> wrote:
>> > I don't have a strong opinion on this.  But for python 2.3 and
>> > 2.4 i guess it's somewhat nice to be able to type "python setup.py install"
>> > and have it work indepedently from the question if
>> > setuptools is installed.
>> >
>>
>> setuptools enabled packages come with a short bootstrap module which
>> does install setuptools in case it is not installed. This should also
>> work with python 2.3.
>> (I think you will also need vs 6.0 instead of vs 2003 to build
>> extensions for python 2.3 on windows)
>
> ok.  if we want to ship with a pre-compiled greenlet module
> we would need to distribute per-python versions, right?

yes.

> If we can't manage this ourselves then i hope we can
> find people to prepare binary eggs.

yes, for mac and windows only I guess. This would be another good
reason to split the greenlet module from the other code. You wouldn't
have to build new binary packages as long as only some python code got
changed..


>
>> > originally the greenlet lib was moved into the py lib
>> > to ease maintenance and because it was used in PyPy and
>> > we didn't want to add dependencies there.
>> >
>> > Today, I'd be fine both ways - for 0.9.2 i guess
>> > greenlets should still be part of the py lib, though.
>> >
>>
>> ok. I'll try to implement a setuptools based setup.py then.
>
> any chances you'll get to that this week?  I think i'd
> like to get the 0.9.2 release out the coming weekend.
>

http://systemexit.de/repo/py-setup/ contains a mercurial repository
with a setup.py using setuptools.
The setup.py itself currently can be viewed here:
http://systemexit.de/repo/py-setup/file/tip/setup.py

It currently only installs a py.test as a script (everything else from
py/bin/ is missing).
It installs the greenlet module under the name greenlet.
py.magic.greenlet should be adapted accordingly.
(You still want to compile it on the fly???). Something like

try:
  import greenlet
except ImportError:
 try_compile()

should work..

You can build a source distribution with
python setup.py build sdist
and a binary egg with
python setup.py build bdist_egg

When doing development you can run python setup.py develop in order to
use the source files in place.

ez_setup.py has been downloaded from
http://peak.telecommunity.com/dist/ez_setup.py
The MANIFEST.in file should not be needed as setuptools would handle
that automatically for a subversion repository.

- Ralf

From holger at merlinux.eu  Wed Aug 13 08:21:29 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 13 Aug 2008 08:21:29 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0808121513t677faa05yca90262a02f1b982@mail.gmail.com>
References: <20080723113426.GS22324@trillke.net>
	<932f8baf0808040120k4f91d2ddh11771803fb2236eb@mail.gmail.com>
	<20080804084131.GL9619@trillke.net>
	<932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>
	<20080804100246.GN9619@trillke.net>
	<932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>
	<20080804134832.GO9619@trillke.net>
	<932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>
	<20080812191631.GH9619@trillke.net>
	<932f8baf0808121513t677faa05yca90262a02f1b982@mail.gmail.com>
Message-ID: <20080813062128.GJ9619@trillke.net>

On Wed, Aug 13, 2008 at 00:13 +0200, Ralf Schmitt wrote:
> On Tue, Aug 12, 2008 at 9:16 PM, holger krekel <holger at merlinux.eu> wrote:
> > Hi Ralf,
> >
> > On Mon, Aug 04, 2008 at 16:11 +0200, Ralf Schmitt wrote:
> >> On Mon, Aug 4, 2008 at 3:48 PM, holger krekel <holger at merlinux.eu> wrote:
> >> > I don't have a strong opinion on this.  But for python 2.3 and
> >> > 2.4 i guess it's somewhat nice to be able to type "python setup.py install"
> >> > and have it work indepedently from the question if
> >> > setuptools is installed.
> >> >
> >>
> >> setuptools enabled packages come with a short bootstrap module which
> >> does install setuptools in case it is not installed. This should also
> >> work with python 2.3.
> >> (I think you will also need vs 6.0 instead of vs 2003 to build
> >> extensions for python 2.3 on windows)
> >
> > ok.  if we want to ship with a pre-compiled greenlet module
> > we would need to distribute per-python versions, right?
> 
> yes.
> 
> > If we can't manage this ourselves then i hope we can
> > find people to prepare binary eggs.
> 
> yes, for mac and windows only I guess. This would be another good
> reason to split the greenlet module from the other code. You wouldn't
> have to build new binary packages as long as only some python code got
> changed..

sure but in any case i don't want to change this going from 0.9.1 to 0.9.2. 

> >> > originally the greenlet lib was moved into the py lib
> >> > to ease maintenance and because it was used in PyPy and
> >> > we didn't want to add dependencies there.
> >> >
> >> > Today, I'd be fine both ways - for 0.9.2 i guess
> >> > greenlets should still be part of the py lib, though.
> >> >
> >>
> >> ok. I'll try to implement a setuptools based setup.py then.
> >
> > any chances you'll get to that this week?  I think i'd
> > like to get the 0.9.2 release out the coming weekend.
> >
> 
> http://systemexit.de/repo/py-setup/ contains a mercurial repository
> with a setup.py using setuptools.
> The setup.py itself currently can be viewed here:
> http://systemexit.de/repo/py-setup/file/tip/setup.py
> 
> It currently only installs a py.test as a script (everything else from
> py/bin/ is missing).
> It installs the greenlet module under the name greenlet.
> py.magic.greenlet should be adapted accordingly.
> (You still want to compile it on the fly???). Something like

I think i'd like to have a flag that turns automatic
compilation on or off. A setup.py installed release 
should have this flag off so that no automatic 
installation occurs. 
 
> try:
>   import greenlet
> except ImportError:
>  try_compile()
> 
> should work..
> 
> You can build a source distribution with
> python setup.py build sdist
> and a binary egg with
> python setup.py build bdist_egg

is it usual to do  binary eggs for linux/osx? 

> When doing development you can run python setup.py develop in order to
> use the source files in place.
> 
> ez_setup.py has been downloaded from
> http://peak.telecommunity.com/dist/ez_setup.py
> The MANIFEST.in file should not be needed as setuptools would handle
> that automatically for a subversion repository.

ah, it looks at all the files that are versioned? 

thanks for the work, btw! 

holger

From schmir at gmail.com  Wed Aug 13 17:24:25 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 13 Aug 2008 17:24:25 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080813062128.GJ9619@trillke.net>
References: <20080723113426.GS22324@trillke.net>
	<20080804084131.GL9619@trillke.net>
	<932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>
	<20080804100246.GN9619@trillke.net>
	<932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>
	<20080804134832.GO9619@trillke.net>
	<932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>
	<20080812191631.GH9619@trillke.net>
	<932f8baf0808121513t677faa05yca90262a02f1b982@mail.gmail.com>
	<20080813062128.GJ9619@trillke.net>
Message-ID: <932f8baf0808130824i257ca1belaf54b01f53ccee3a@mail.gmail.com>

On Wed, Aug 13, 2008 at 8:21 AM, holger krekel <holger at merlinux.eu> wrote:

>
> sure but in any case i don't want to change this going from 0.9.1 to 0.9.2.

ack.

>
> I think i'd like to have a flag that turns automatic
> compilation on or off. A setup.py installed release
> should have this flag off so that no automatic
> installation occurs.

I've implemented this in http://systemexit.de/repo/py-setup/rev/4e18f70b985d.
The flag used here is the existence of greenlet.c in py/c-extensions/greenlet/.


>
> is it usual to do  binary eggs for linux/osx?

linux no. osx probably. some people might not have xcode installed.


>> The MANIFEST.in file should not be needed as setuptools would handle
>> that automatically for a subversion repository.
>
> ah, it looks at all the files that are versioned?
>

yes

From schmir at gmail.com  Wed Aug 13 18:06:57 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 13 Aug 2008 18:06:57 +0200
Subject: [py-dev] SyntaxWarning: assertion is always true
Message-ID: <932f8baf0808130906y5a46df14r3fec7bb00ddab58d@mail.gmail.com>

Hi,

minor issue, but you probably want to fix it:

/home/ralf/py26/lib/python2.6/site-packages/py-0.9.2_pre_alpha-py2.6-linux-x86_64.egg/py/apigen/linker.py:33:
SyntaxWarning: assertion is always true, perhaps remove parentheses?
  assert (linkid not in self._linkid2target,

- Ralf

From holger at merlinux.eu  Wed Aug 13 18:23:20 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 13 Aug 2008 18:23:20 +0200
Subject: [py-dev] SyntaxWarning: assertion is always true
In-Reply-To: <932f8baf0808130906y5a46df14r3fec7bb00ddab58d@mail.gmail.com>
References: <932f8baf0808130906y5a46df14r3fec7bb00ddab58d@mail.gmail.com>
Message-ID: <20080813162320.GO9619@trillke.net>

On Wed, Aug 13, 2008 at 18:06 +0200, Ralf Schmitt wrote:
> minor issue, but you probably want to fix it:
> 
> /home/ralf/py26/lib/python2.6/site-packages/py-0.9.2_pre_alpha-py2.6-linux-x86_64.egg/py/apigen/linker.py:33:
> SyntaxWarning: assertion is always true, perhaps remove parentheses?
>   assert (linkid not in self._linkid2target,

fixed, i shifted the left parenthesis to after the comma. 
holger

From holger at merlinux.eu  Wed Aug 13 18:32:41 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 13 Aug 2008 18:32:41 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0808130824i257ca1belaf54b01f53ccee3a@mail.gmail.com>
References: <20080804084131.GL9619@trillke.net>
	<932f8baf0808040201w61f53f03l99f188249ba67c99@mail.gmail.com>
	<20080804100246.GN9619@trillke.net>
	<932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>
	<20080804134832.GO9619@trillke.net>
	<932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>
	<20080812191631.GH9619@trillke.net>
	<932f8baf0808121513t677faa05yca90262a02f1b982@mail.gmail.com>
	<20080813062128.GJ9619@trillke.net>
	<932f8baf0808130824i257ca1belaf54b01f53ccee3a@mail.gmail.com>
Message-ID: <20080813163241.GP9619@trillke.net>

On Wed, Aug 13, 2008 at 17:24 +0200, Ralf Schmitt wrote:
> On Wed, Aug 13, 2008 at 8:21 AM, holger krekel <holger at merlinux.eu> wrote:
> 
> >
> > sure but in any case i don't want to change this going from 0.9.1 to 0.9.2.
> 
> ack.
> 
> >
> > I think i'd like to have a flag that turns automatic
> > compilation on or off. A setup.py installed release
> > should have this flag off so that no automatic
> > installation occurs.
> 
> I've implemented this in http://systemexit.de/repo/py-setup/rev/4e18f70b985d.
> The flag used here is the existence of greenlet.c in py/c-extensions/greenlet/.

ok, i'll check this. 

another thing with setuptools: the way that py.test is
installed as a console script modifies the py lib lookup:
py/bin/py.test usually looks for a py lib upwards 
from where you invokve it (the curdir) with the help of _findpy.py.  

this is important at least for pypy and when you are using py.test 
to work on the py lib itself.   Do you have an idea 
how to preserve this logic with setuptools?  Specifying
a module import path probably does not work because
then there is no chance anymore to influence which 
py lib gets loaded. 

holger

From schmir at gmail.com  Wed Aug 13 19:14:25 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 13 Aug 2008 19:14:25 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080813163241.GP9619@trillke.net>
References: <20080804084131.GL9619@trillke.net>
	<20080804100246.GN9619@trillke.net>
	<932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>
	<20080804134832.GO9619@trillke.net>
	<932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>
	<20080812191631.GH9619@trillke.net>
	<932f8baf0808121513t677faa05yca90262a02f1b982@mail.gmail.com>
	<20080813062128.GJ9619@trillke.net>
	<932f8baf0808130824i257ca1belaf54b01f53ccee3a@mail.gmail.com>
	<20080813163241.GP9619@trillke.net>
Message-ID: <932f8baf0808131014m53e60fc6q148d5b7e4367f34f@mail.gmail.com>

On Wed, Aug 13, 2008 at 6:32 PM, holger krekel <holger at merlinux.eu> wrote:

> another thing with setuptools: the way that py.test is
> installed as a console script modifies the py lib lookup:
> py/bin/py.test usually looks for a py lib upwards
> from where you invokve it (the curdir) with the help of _findpy.py.
>

sometimes I have the feeling that you're using too much magic...

> this is important at least for pypy and when you are using py.test
> to work on the py lib itself.   Do you have an idea
> how to preserve this logic with setuptools?  Specifying
> a module import path probably does not work because
> then there is no chance anymore to influence which
> py lib gets loaded.

setuptools creates the following py.test script for me:

#!/home/ralf/py26/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'py==0.9.2-pre-alpha','console_scripts','py.test'
__requires__ = 'py==0.9.2-pre-alpha'
import sys
from pkg_resources import load_entry_point

sys.exit(
   load_entry_point('py==0.9.2-pre-alpha', 'console_scripts', 'py.test')()
)

I would rather be surprised if it used anything else than py lib
version 0.9.2.-pre-alpha.
Can't you just use the inplace installation? (i.e. eval py/env.py)?
py/bin/py.test is still there..

- Ralf

From holger at merlinux.eu  Wed Aug 13 19:40:47 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 13 Aug 2008 19:40:47 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0808131014m53e60fc6q148d5b7e4367f34f@mail.gmail.com>
References: <20080804100246.GN9619@trillke.net>
	<932f8baf0808040557l24e7ec14m703f0c22e0cbd8dc@mail.gmail.com>
	<20080804134832.GO9619@trillke.net>
	<932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>
	<20080812191631.GH9619@trillke.net>
	<932f8baf0808121513t677faa05yca90262a02f1b982@mail.gmail.com>
	<20080813062128.GJ9619@trillke.net>
	<932f8baf0808130824i257ca1belaf54b01f53ccee3a@mail.gmail.com>
	<20080813163241.GP9619@trillke.net>
	<932f8baf0808131014m53e60fc6q148d5b7e4367f34f@mail.gmail.com>
Message-ID: <20080813174047.GQ9619@trillke.net>

Hi Ralf, 

On Wed, Aug 13, 2008 at 19:14 +0200, Ralf Schmitt wrote:
> On Wed, Aug 13, 2008 at 6:32 PM, holger krekel <holger at merlinux.eu> wrote:
> 
> > another thing with setuptools: the way that py.test is
> > installed as a console script modifies the py lib lookup:
> > py/bin/py.test usually looks for a py lib upwards
> > from where you invokve it (the curdir) with the help of _findpy.py.
> 
> sometimes I have the feeling that you're using too much magic...

hum, it's a feature that has been of use to some people.  
let me ask: has it ever hit you badly?

> > this is important at least for pypy and when you are using py.test
> > to work on the py lib itself.   Do you have an idea
> > how to preserve this logic with setuptools?  Specifying
> > a module import path probably does not work because
> > then there is no chance anymore to influence which
> > py lib gets loaded.
> 
> setuptools creates the following py.test script for me:
> 
> #!/home/ralf/py26/bin/python
> # EASY-INSTALL-ENTRY-SCRIPT: 'py==0.9.2-pre-alpha','console_scripts','py.test'
> __requires__ = 'py==0.9.2-pre-alpha'
> import sys
> from pkg_resources import load_entry_point
> 
> sys.exit(
>    load_entry_point('py==0.9.2-pre-alpha', 'console_scripts', 'py.test')()
> )
> 
> I would rather be surprised if it used anything else than py lib
> version 0.9.2.-pre-alpha.

sure, but this is what setuptools creates, it's not what
py/bin/py.test specifies and what gets installed with a
distutils install.  

> Can't you just use the inplace installation? (i.e. eval py/env.py)?
> py/bin/py.test is still there..

i guess i could and probably also the others.  I'll think about it. 

If others like to chime in here, please do so. 

I can also imagine to just use a normal distutils setup.py 
for 0.9.2 based on what you did.  I recently i even had someone
not wanting to use setuptools based installs (for a different
project).  Btw, I actually assumed that python 2.5 came with setuptools 
but that is not the case, has just been discussed at some point, right? 

holger

From schmir at gmail.com  Wed Aug 13 19:51:49 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 13 Aug 2008 19:51:49 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080813174047.GQ9619@trillke.net>
References: <20080804100246.GN9619@trillke.net>
	<20080804134832.GO9619@trillke.net>
	<932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>
	<20080812191631.GH9619@trillke.net>
	<932f8baf0808121513t677faa05yca90262a02f1b982@mail.gmail.com>
	<20080813062128.GJ9619@trillke.net>
	<932f8baf0808130824i257ca1belaf54b01f53ccee3a@mail.gmail.com>
	<20080813163241.GP9619@trillke.net>
	<932f8baf0808131014m53e60fc6q148d5b7e4367f34f@mail.gmail.com>
	<20080813174047.GQ9619@trillke.net>
Message-ID: <932f8baf0808131051v7962d450xa17f05b2d21c8f60@mail.gmail.com>

On Wed, Aug 13, 2008 at 7:40 PM, holger krekel <holger at merlinux.eu> wrote:
>
> hum, it's a feature that has been of use to some people.
> let me ask: has it ever hit you badly?
>

not yet :)

>> Can't you just use the inplace installation? (i.e. eval py/env.py)?
>> py/bin/py.test is still there..
>
> i guess i could and probably also the others.  I'll think about it.

searching for the py lib and calling exec with another py.test (if py
lib is found) sounds like a clean solution (on unix platforms)....

>
> If others like to chime in here, please do so.
>
> I can also imagine to just use a normal distutils setup.py
> for 0.9.2 based on what you did.  I recently i even had someone
> not wanting to use setuptools based installs (for a different
> project).  Btw, I actually assumed that python 2.5 came with setuptools
> but that is not the case, has just been discussed at some point, right?

it's automatically installed.


Regards,
- Ralf

From holger at merlinux.eu  Wed Aug 13 19:55:29 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 13 Aug 2008 19:55:29 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0808131051v7962d450xa17f05b2d21c8f60@mail.gmail.com>
References: <20080804134832.GO9619@trillke.net>
	<932f8baf0808040711ne4e933fn73998bbe6023dd1e@mail.gmail.com>
	<20080812191631.GH9619@trillke.net>
	<932f8baf0808121513t677faa05yca90262a02f1b982@mail.gmail.com>
	<20080813062128.GJ9619@trillke.net>
	<932f8baf0808130824i257ca1belaf54b01f53ccee3a@mail.gmail.com>
	<20080813163241.GP9619@trillke.net>
	<932f8baf0808131014m53e60fc6q148d5b7e4367f34f@mail.gmail.com>
	<20080813174047.GQ9619@trillke.net>
	<932f8baf0808131051v7962d450xa17f05b2d21c8f60@mail.gmail.com>
Message-ID: <20080813175529.GR9619@trillke.net>

On Wed, Aug 13, 2008 at 19:51 +0200, Ralf Schmitt wrote:
> On Wed, Aug 13, 2008 at 7:40 PM, holger krekel <holger at merlinux.eu> wrote:
> > Btw, I actually assumed that python 2.5 came with setuptools
> > but that is not the case, has just been discussed at some point, right?
> 
> it's automatically installed.

ok - but not included with python 2.5, despite
http://mail.python.org/pipermail/python-dev/2006-April/063964.html

or am i getting this wrong? 
best,
holger

From schmir at gmail.com  Wed Aug 13 20:02:10 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 13 Aug 2008 20:02:10 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080813175529.GR9619@trillke.net>
References: <20080804134832.GO9619@trillke.net>
	<20080812191631.GH9619@trillke.net>
	<932f8baf0808121513t677faa05yca90262a02f1b982@mail.gmail.com>
	<20080813062128.GJ9619@trillke.net>
	<932f8baf0808130824i257ca1belaf54b01f53ccee3a@mail.gmail.com>
	<20080813163241.GP9619@trillke.net>
	<932f8baf0808131014m53e60fc6q148d5b7e4367f34f@mail.gmail.com>
	<20080813174047.GQ9619@trillke.net>
	<932f8baf0808131051v7962d450xa17f05b2d21c8f60@mail.gmail.com>
	<20080813175529.GR9619@trillke.net>
Message-ID: <932f8baf0808131102o1cd17e46y7fecce92b572e46b@mail.gmail.com>

On Wed, Aug 13, 2008 at 7:55 PM, holger krekel <holger at merlinux.eu> wrote:
> On Wed, Aug 13, 2008 at 19:51 +0200, Ralf Schmitt wrote:
>> On Wed, Aug 13, 2008 at 7:40 PM, holger krekel <holger at merlinux.eu> wrote:
>> > Btw, I actually assumed that python 2.5 came with setuptools
>> > but that is not the case, has just been discussed at some point, right?
>>
>> it's automatically installed.
>
> ok - but not included with python 2.5, despite
> http://mail.python.org/pipermail/python-dev/2006-April/063964.html
>
> or am i getting this wrong?

no, setuptools is not included. it will also *not* be in 2.6.

- Ralf

From fijal at genesilico.pl  Thu Aug 14 09:45:04 2008
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Thu, 14 Aug 2008 09:45:04 +0200
Subject: [py-dev] broken/notimplemented?
In-Reply-To: <486E323E.6060500@johnnydebris.net>
References: <20080704065051.GN759@trillke.net>
	<486E323E.6060500@johnnydebris.net>
Message-ID: <48A3E280.6080601@genesilico.pl>

Guido Wesdorp wrote:
> holger krekel wrote:
>   
>> in the 0.9.1 release i see that "py.test.broken" and
>> "py.test.notimplemented" were introduced into the namespace.
>> What is the rationale?  
>>
>>   
>>     
> Hm, doesn't ring a bell, I probably have merged them in because there 
> seemed to be a dependency on them from other bits of code, or because 
> the checkin was part of other changes, or even because the checkin 
> message for the change was confusing... Anyway, not sure if they can 
> just go, I guess it's best to ask Maciek.
>
> Cheers,
>
> Guido
>   
I think I had at some point some idea about that, but I don't remember 
details.

From holger at merlinux.eu  Thu Aug 14 12:33:55 2008
From: holger at merlinux.eu (holger krekel)
Date: Thu, 14 Aug 2008 12:33:55 +0200
Subject: [py-dev] setuptools and PYTHONPATH
Message-ID: <20080814103355.GV9619@trillke.net>

Hi Ralf, all,

so when i have installed a py egg - i seem to
have problems getting my PYTHONPATH env variable
respected.  i refer to this situation

- executed ralf's "setup.py" install 
- PYTHONPATH=/some/path/to/py/lib/branchdir
- python && "import py" && "py.__file__"
  points to the egg still

Does setuptools really force global installation 
over private environment settings? 

(i wouldn't regard the need to do "python 
setup.py develop" or something like a 
convenient solution, btw)

best,

holger

From schmir at gmail.com  Thu Aug 14 13:11:55 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Thu, 14 Aug 2008 13:11:55 +0200
Subject: [py-dev] setuptools and PYTHONPATH
In-Reply-To: <20080814103355.GV9619@trillke.net>
References: <20080814103355.GV9619@trillke.net>
Message-ID: <932f8baf0808140411l14bd6625r1572929cc4442858@mail.gmail.com>

On Thu, Aug 14, 2008 at 12:33 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Ralf, all,
>
> so when i have installed a py egg - i seem to
> have problems getting my PYTHONPATH env variable
> respected.  i refer to this situation
>
> - executed ralf's "setup.py" install
> - PYTHONPATH=/some/path/to/py/lib/branchdir
> - python && "import py" && "py.__file__"
>  points to the egg still
>
> Does setuptools really force global installation
> over private environment settings?
>

See http://www.eby-sarna.com/pipermail/peak/2006-June/002582.html for
a discussion.
You can deactivate the installed package with easy_install -m py.

- Ralf

From schmir at gmail.com  Thu Aug 14 13:46:28 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Thu, 14 Aug 2008 13:46:28 +0200
Subject: [py-dev] setuptools and PYTHONPATH
In-Reply-To: <932f8baf0808140411l14bd6625r1572929cc4442858@mail.gmail.com>
References: <20080814103355.GV9619@trillke.net>
	<932f8baf0808140411l14bd6625r1572929cc4442858@mail.gmail.com>
Message-ID: <932f8baf0808140446q424ff47dq4e8070b221e43044@mail.gmail.com>

On Thu, Aug 14, 2008 at 1:11 PM, Ralf Schmitt <schmir at gmail.com> wrote:
>> Does setuptools really force global installation
>> over private environment settings?
>>
>
> See http://www.eby-sarna.com/pipermail/peak/2006-June/002582.html for
> a discussion.
> You can deactivate the installed package with easy_install -m py.
>

>From the same thread
(http://www.eby-sarna.com/pipermail/peak/2006-June/002584.html):
"""
This isn't what you want.  What you want to do is point PYTHONPATH to a
staging directory of some sort, and put that directory on the "develop"
line.  What you're doing here is trying to install the library *onto
itself*.  -d and PYTHONPATH need to be some *other* location, to which
you're installing.


>which overrides the site-packages version, but also requires root
>access.  how would I do this without requiring root access ?

mkdir ~/py_lib
export PYTHONPATH=~/py_lib
cd ~/sa020
python setup.py develop -d ~/py_lib
"""

i.e. you need to put the egg on PYTHONPATH in order to override the
system wide installation, *not* the directory which contains the
source code.

- Ralf

From holger at merlinux.eu  Thu Aug 14 14:27:14 2008
From: holger at merlinux.eu (holger krekel)
Date: Thu, 14 Aug 2008 14:27:14 +0200
Subject: [py-dev] setuptools and PYTHONPATH
In-Reply-To: <932f8baf0808140446q424ff47dq4e8070b221e43044@mail.gmail.com>
References: <20080814103355.GV9619@trillke.net>
	<932f8baf0808140411l14bd6625r1572929cc4442858@mail.gmail.com>
	<932f8baf0808140446q424ff47dq4e8070b221e43044@mail.gmail.com>
Message-ID: <20080814122714.GW9619@trillke.net>

On Thu, Aug 14, 2008 at 13:46 +0200, Ralf Schmitt wrote:
> On Thu, Aug 14, 2008 at 1:11 PM, Ralf Schmitt <schmir at gmail.com> wrote:
> >> Does setuptools really force global installation
> >> over private environment settings?
> >>
> >
> > See http://www.eby-sarna.com/pipermail/peak/2006-June/002582.html for
> > a discussion.
> > You can deactivate the installed package with easy_install -m py.
> >
> 
> >From the same thread
> (http://www.eby-sarna.com/pipermail/peak/2006-June/002584.html):
> """
> This isn't what you want.  What you want to do is point PYTHONPATH to a
> staging directory of some sort, and put that directory on the "develop"
> line.  What you're doing here is trying to install the library *onto
> itself*.  -d and PYTHONPATH need to be some *other* location, to which
> you're installing.
> 
> 
> >which overrides the site-packages version, but also requires root
> >access.  how would I do this without requiring root access ?
> 
> mkdir ~/py_lib
> export PYTHONPATH=~/py_lib
> cd ~/sa020
> python setup.py develop -d ~/py_lib
> """
> 
> i.e. you need to put the egg on PYTHONPATH in order to override the
> system wide installation, *not* the directory which contains the
> source code.

thanks for the info and clarification. 

looks inconvenient and IMHO changes the basic PYTHONPATH
expectation - as noted down in 
http://docs.python.org/tut/node8.html#SECTION008120000000000000000

actually i don't really see why setuptools has to violate this. 

holger

From fijal at genesilico.pl  Thu Aug 14 14:32:42 2008
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Thu, 14 Aug 2008 14:32:42 +0200
Subject: [py-dev] oncoming 0.9.2 release
In-Reply-To: <20080723105443.GQ22324@trillke.net>
References: <7be3f35d0807230120y3cc20515x68ebfd7322a21bed@mail.gmail.com>
	<20080723105443.GQ22324@trillke.net>
Message-ID: <48A425EA.2080505@genesilico.pl>

holger krekel wrote:
> Hi Harald, 
>
> On Wed, Jul 23, 2008 at 10:20 +0200, Harald Armin Massa wrote:
>   
>> Whish-list:
>>
>> pytest -e
>> pytest --testforever
>>
>> includes --startsserver and --runbrowser, loops "forever" until
>> Ctrl+Break on the given file / directory / filtered files and
>> publishes results on Webport.
>> Bonus points for really showing a traffic light :)
>>     
>
> :) 
>
> This is nothing for 0.9.2, i am afraid.  Particularly 
> since i am relatively clueless about the browser reporter
> currently.  But if you are up to do a patch that does
> what you suggest i'd consider it. 
>
> sidenote: I promise to support anyone going for
> a (new) nice AJAX frontend :)  
>   
I know a bit about AJAX frontend and I promise to support anyone that'll 
go for a better one definitely :-)

I think writing javascript by hand instead of using pypy would simplify 
stuff a bit.

Cheers,
fijal

From monopocalypse+py-dev at gmail.com  Sat Aug 16 06:27:02 2008
From: monopocalypse+py-dev at gmail.com (Matthew Edwards)
Date: Sat, 16 Aug 2008 16:27:02 +1200
Subject: [py-dev] WindowsErrors when removing file (file in use)
Message-ID: <4025a36d0808152127q4bfb2601v2b9ca056396f2e65@mail.gmail.com>

Hi,

This kind of relates to my last problem. With my new file-related test
setup, I often get WindowsErrors when removing files, because they are still
in use, because for some reason the file objects refuse to be closed or
deleted, and are still wandering around when teardown_method is called.
Again, I'm not sure whether this is something I'm doing wrong or a bug, but
I've attached a test (simplified, with attempts at debugging), which fails
with the error every second run (every other run the file exists at the
start) on Python 2.5.2, py 0.9.1 or svn 57262, Windows XP.

Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20080816/94da5fde/attachment.htm 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_remove.py
Url: http://codespeak.net/pipermail/py-dev/attachments/20080816/94da5fde/attachment.diff 

From johnny at johnnydebris.net  Sat Aug 16 10:22:08 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Sat, 16 Aug 2008 10:22:08 +0200
Subject: [py-dev] WindowsErrors when removing file (file in use)
In-Reply-To: <4025a36d0808152127q4bfb2601v2b9ca056396f2e65@mail.gmail.com>
References: <4025a36d0808152127q4bfb2601v2b9ca056396f2e65@mail.gmail.com>
Message-ID: <48A68E30.9060205@johnnydebris.net>

Matthew Edwards wrote:

...
>             logger = Logger(open(self.filename, 'wb'))
>             for packet in self.subjects:
>                 logger.recv(packet.data)
>             logger.file.close()
>   
If something goes wrong in the recv() call, the log file will not be 
closed with this code (something similar happens later with the reader). 
Could you try if things are better when you use try/finally to make sure 
that the file is closed:

fp = open(self.filename, 'wb')
try:
    logger = Logger(fp)
    for packet in self.subjects:
        logger.recv(packet.data)
finally:
    fp.close()

Hope that helps!

Cheers,

Guido

From holger at merlinux.eu  Sat Aug 16 20:33:00 2008
From: holger at merlinux.eu (holger krekel)
Date: Sat, 16 Aug 2008 20:33:00 +0200
Subject: [py-dev] svn st --xml support for py.path - progress
In-Reply-To: <489BF3E5.70205@johnnydebris.net>
References: <48903F5C.5010306@johnnydebris.net>
	<489B5D6C.8000402@johnnydebris.net>
	<20080808061012.GU9619@trillke.net>
	<489BF3E5.70205@johnnydebris.net>
Message-ID: <20080816183300.GD9619@trillke.net>

Hi Guido!

On Fri, Aug 08, 2008 at 09:21 +0200, Guido Wesdorp wrote:
> holger krekel wrote:
> >> Also tested SVN 1.5 on Windows XP, which fails, but that also happens 
> >> with trunk...
> >>     
> >
> > could you attach a textual log of the failures? 
> >   
> Hrmph, not easily, but I'll do my best (nice to work on a platform where 
> e.g. copy/paste from a console doesn't work)...
> 
> > did you get to check the degraded test speed? 
> >
> >   
> Ah, right, did that just now... I fear the problem is that SVN 
> interaction is just slow, there's a test (test_status_conflict) that 
> takes about 7 seconds to run on my machine, while I don't think it does 
> anything unexpected... It just creates a second wc, checks out the repo, 
> does some writes and commits and checks for conflicts, which I guess is 
> what it _should_ do. I already changed it so that it doesn't build its 
> own repo anymore, but still it takes a _long_ time to run - i fear the 
> problem is just SVN. :(

i guess any test that takes more than two seconds  should be
categorized as slow and only run when --runslowtests is
enabled.  Could you do this and otherwise merge the branch
to trunk?   

best & thanks! 

holger

From holger at merlinux.eu  Mon Aug 18 15:52:44 2008
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Aug 2008 15:52:44 +0200
Subject: [py-dev] 0.9.2 alpha eggs - please test
Message-ID: <20080818135244.GI9619@trillke.net>

Hi all, 

i am experimenting with building eggs and installation
improvements, particularly for windows but also for unix.  
Would be great if you could give "easy_install" with one of
these packages a try and report back any problems: 

    http://codespeak.net/~hpk/py/dist/

This should work nicely out of the box, including
accessing "py.magic.greenlet" (the stackless light
c-extension) and running "py.test" on the command line
on your project. 

You should be able to remove all previous hacks, 
additions to the PATH environment setting. 

thanks & best, 
holger

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

From holger at merlinux.eu  Mon Aug 18 15:54:51 2008
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Aug 2008 15:54:51 +0200
Subject: [py-dev] 0.9.2 alpha eggs - please test
In-Reply-To: <20080818135244.GI9619@trillke.net>
References: <20080818135244.GI9619@trillke.net>
Message-ID: <20080818135451.GJ9619@trillke.net>

On Mon, Aug 18, 2008 at 15:52 +0200, holger krekel wrote:
> i am experimenting with building eggs and installation
> improvements, particularly for windows but also for unix.  
> Would be great if you could give "easy_install" with one of
> these packages a try and report back any problems: 
> 
>     http://codespeak.net/~hpk/py/dist/

i assume you know that you can do "easy_install URL_TO_EGG". 

holger

From holger at merlinux.eu  Mon Aug 18 16:44:12 2008
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Aug 2008 16:44:12 +0200
Subject: [py-dev] setuptools and PYTHONPATH
In-Reply-To: <20080814122714.GW9619@trillke.net>
References: <20080814103355.GV9619@trillke.net>
	<932f8baf0808140411l14bd6625r1572929cc4442858@mail.gmail.com>
	<932f8baf0808140446q424ff47dq4e8070b221e43044@mail.gmail.com>
	<20080814122714.GW9619@trillke.net>
Message-ID: <20080818144412.GK9619@trillke.net>

Hi Ralf, 

with your setup script installing the py.* scripts didn't work
on windows where setuptools created "py.test.exe" but this is
not looked up by the windows command line when you type
"py.test".  I experimented a bit and think i found a somewhat
sensible solution for the windows issue. 

As to the way scripts are installed in general - i am just
using the "scripts" keyword now, not the setuptools specific
one and it seems to work well.  See the new
svn/py/release/0.9.x/setup.py.  This setup script works also
works with plain distutils.  It's generated by
svn/py/build/gensetup.py and it's thus easy to apply
systematic changes. 

thanks for your setup.py, anyway - was useful to look at. 

holger


On Thu, Aug 14, 2008 at 14:27 +0200, holger krekel wrote:
> On Thu, Aug 14, 2008 at 13:46 +0200, Ralf Schmitt wrote:
> > On Thu, Aug 14, 2008 at 1:11 PM, Ralf Schmitt <schmir at gmail.com> wrote:
> > >> Does setuptools really force global installation
> > >> over private environment settings?
> > >>
> > >
> > > See http://www.eby-sarna.com/pipermail/peak/2006-June/002582.html for
> > > a discussion.
> > > You can deactivate the installed package with easy_install -m py.
> > >
> > 
> > >From the same thread
> > (http://www.eby-sarna.com/pipermail/peak/2006-June/002584.html):
> > """
> > This isn't what you want.  What you want to do is point PYTHONPATH to a
> > staging directory of some sort, and put that directory on the "develop"
> > line.  What you're doing here is trying to install the library *onto
> > itself*.  -d and PYTHONPATH need to be some *other* location, to which
> > you're installing.
> > 
> > 
> > >which overrides the site-packages version, but also requires root
> > >access.  how would I do this without requiring root access ?
> > 
> > mkdir ~/py_lib
> > export PYTHONPATH=~/py_lib
> > cd ~/sa020
> > python setup.py develop -d ~/py_lib
> > """
> > 
> > i.e. you need to put the egg on PYTHONPATH in order to override the
> > system wide installation, *not* the directory which contains the
> > source code.
> 
> thanks for the info and clarification. 
> 
> looks inconvenient and IMHO changes the basic PYTHONPATH
> expectation - as noted down in 
> http://docs.python.org/tut/node8.html#SECTION008120000000000000000
> 
> actually i don't really see why setuptools has to violate this. 
> 
> holger
> 

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

From haraldarminmassa at gmail.com  Tue Aug 19 09:17:42 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 19 Aug 2008 09:17:42 +0200
Subject: [py-dev] 0.9.2 alpha eggs - please test
In-Reply-To: <20080818135451.GJ9619@trillke.net>
References: <20080818135244.GI9619@trillke.net>
	<20080818135451.GJ9619@trillke.net>
Message-ID: <7be3f35d0808190017w3db68e58rf4970a4c69e444d2@mail.gmail.com>

Holger,

>>     http://codespeak.net/~hpk/py/dist/
>
> i assume you know that you can do "easy_install URL_TO_EGG".
>
Thanks for typing out the assumption :) I did an easy install, and it
worked, also copied a greenlet test from the documentation and it
printed as expected.

Improvement suggestion: Put out a small .html with the total file
names. Actually Firefox only lists the name as py-0.9.2_alpha_7-py2..>

so some mousing over is required to judge if it fits for 2.5 or 2.4 ...

best wishes,

Harald


-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!

From haraldarminmassa at gmail.com  Tue Aug 19 09:25:12 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 19 Aug 2008 09:25:12 +0200
Subject: [py-dev] 0.9.2 alpha eggs - please test
In-Reply-To: <7be3f35d0808190017w3db68e58rf4970a4c69e444d2@mail.gmail.com>
References: <20080818135244.GI9619@trillke.net>
	<20080818135451.GJ9619@trillke.net>
	<7be3f35d0808190017w3db68e58rf4970a4c69e444d2@mail.gmail.com>
Message-ID: <7be3f35d0808190025t473743f4w5cf7affa35715786@mail.gmail.com>

Holger,

other test results:

----> py-0.9.2_alpha_7-py2..>

installs flawless.

But: there are a lot of useless things copied to python25\scripts:

py.cleanup.cmd
py.countloc.cmd
py.lookup.cmd
py.rest.cmd
py.test.cmd

do not have ANY use on windows, as  windows tries to open "py.cleanup"
when typin py.cleanup; which of course fails.

Recommendation: rename those to pycleanup.cmd, pycountloc.cmd etc.

Best wishes,

Harald




-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!

From schmir at gmail.com  Tue Aug 19 09:31:04 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Tue, 19 Aug 2008 09:31:04 +0200
Subject: [py-dev] 0.9.2 alpha eggs - please test
In-Reply-To: <7be3f35d0808190017w3db68e58rf4970a4c69e444d2@mail.gmail.com>
References: <20080818135244.GI9619@trillke.net>
	<20080818135451.GJ9619@trillke.net>
	<7be3f35d0808190017w3db68e58rf4970a4c69e444d2@mail.gmail.com>
Message-ID: <932f8baf0808190031i57ae1a6vf72efcd2caf2682b@mail.gmail.com>

On Tue, Aug 19, 2008 at 9:17 AM, Harald Armin Massa
<haraldarminmassa at gmail.com> wrote:
> Holger,
>
>>>     http://codespeak.net/~hpk/py/dist/
>>
>> i assume you know that you can do "easy_install URL_TO_EGG".
>>
> Thanks for typing out the assumption :) I did an easy install, and it
> worked, also copied a greenlet test from the documentation and it
> printed as expected.
>

same here, everything seems to work.
 I've tested (a litte bit) with OS X (python 2.5) and with python 2.6
on a linux box...

- Ralf

From schmir at gmail.com  Tue Aug 19 09:35:31 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Tue, 19 Aug 2008 09:35:31 +0200
Subject: [py-dev] setuptools and PYTHONPATH
In-Reply-To: <20080818144412.GK9619@trillke.net>
References: <20080814103355.GV9619@trillke.net>
	<932f8baf0808140411l14bd6625r1572929cc4442858@mail.gmail.com>
	<932f8baf0808140446q424ff47dq4e8070b221e43044@mail.gmail.com>
	<20080814122714.GW9619@trillke.net>
	<20080818144412.GK9619@trillke.net>
Message-ID: <932f8baf0808190035q3d6ad395p41a6ba488961c051@mail.gmail.com>

On Mon, Aug 18, 2008 at 4:44 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Ralf,
>
> with your setup script installing the py.* scripts didn't work
> on windows where setuptools created "py.test.exe" but this is
> not looked up by the windows command line when you type
> "py.test".  I experimented a bit and think i found a somewhat
> sensible solution for the windows issue.
>

strange. I'm pretty sure this *must* work. (Or is ther a problem with
the two dots?)

Regards,
- Ralf

From holger at merlinux.eu  Tue Aug 19 10:36:09 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 19 Aug 2008 10:36:09 +0200
Subject: [py-dev] setuptools and PYTHONPATH
In-Reply-To: <932f8baf0808190035q3d6ad395p41a6ba488961c051@mail.gmail.com>
References: <20080814103355.GV9619@trillke.net>
	<932f8baf0808140411l14bd6625r1572929cc4442858@mail.gmail.com>
	<932f8baf0808140446q424ff47dq4e8070b221e43044@mail.gmail.com>
	<20080814122714.GW9619@trillke.net>
	<20080818144412.GK9619@trillke.net>
	<932f8baf0808190035q3d6ad395p41a6ba488961c051@mail.gmail.com>
Message-ID: <20080819083609.GQ9619@trillke.net>

On Tue, Aug 19, 2008 at 09:35 +0200, Ralf Schmitt wrote:
> On Mon, Aug 18, 2008 at 4:44 PM, holger krekel <holger at merlinux.eu> wrote:
> > Hi Ralf,
> >
> > with your setup script installing the py.* scripts didn't work
> > on windows where setuptools created "py.test.exe" but this is
> > not looked up by the windows command line when you type
> > "py.test".  I experimented a bit and think i found a somewhat
> > sensible solution for the windows issue.
> >
> 
> strange. I'm pretty sure this *must* work. (Or is ther a problem with
> the two dots?)

right, i *guess* it's windows not checking because of the two
dots.   holger

From holger at merlinux.eu  Tue Aug 19 10:57:23 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 19 Aug 2008 10:57:23 +0200
Subject: [py-dev] 0.9.2 alpha eggs - please test
In-Reply-To: <7be3f35d0808190025t473743f4w5cf7affa35715786@mail.gmail.com>
References: <20080818135244.GI9619@trillke.net>
	<20080818135451.GJ9619@trillke.net>
	<7be3f35d0808190017w3db68e58rf4970a4c69e444d2@mail.gmail.com>
	<7be3f35d0808190025t473743f4w5cf7affa35715786@mail.gmail.com>
Message-ID: <20080819085723.GR9619@trillke.net>

Hi Harald, 

On Tue, Aug 19, 2008 at 09:25 +0200, Harald Armin Massa wrote:
> other test results:
> 
> ----> py-0.9.2_alpha_7-py2..>
> 
> installs flawless.
> 
> But: there are a lot of useless things copied to python25\scripts:
> 
> py.cleanup.cmd
> py.countloc.cmd
> py.lookup.cmd
> py.rest.cmd
> py.test.cmd
> 
> do not have ANY use on windows, as  windows tries to open "py.cleanup"
> when typin py.cleanup; which of course fails.

hum, i think this relates to earlier installs and/or your 
PATH settings.  the above egg does not install "py.*". 
What it does is this (see "def run" at the end of 
http://codespeak.net/svn/py/release/0.9.x/setup.py): 
rename 
    py.test, py.rest, etc. to 
    py_test, py_rest, etc. 

in the Python25/Scripts dir and create py.test.cmd, py.rest.cmd, ...
helpers which calls the underscore scripts. 

But indeed, if one installs 0.9.1 and then 0.9.2-alpha one cannot 
use "py.test" out of the box.  This relates to the old PATH hacks. 
The new egg does not need to add to PATH which i think is good.  
So i guess I am going to work to try to fix things by
going through the PATH and pruning out "py/bin/" PATHS
if they look like py lib ones.  Actually i think it
makes sense to try to undo this PATH addition while
upgrading, anyway.  
 
> Recommendation: rename those to pycleanup.cmd, pycountloc.cmd etc.

i'd like to have uniforming naming if possible. 

on two sidenotes, i wonder why setuptools does not automatically 
delete the old py lib version and if there is a setuptool-supported
way of uninstalling packages. 

many thanks for noting this, 
holger

From holger at merlinux.eu  Tue Aug 19 14:36:38 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 19 Aug 2008 14:36:38 +0200
Subject: [py-dev] setuptools / undoing 0.9.1 PATH hacks (Re: 0.9.2
	alpha	eggs - please test)
In-Reply-To: <20080819085723.GR9619@trillke.net>
References: <20080818135244.GI9619@trillke.net>
	<20080818135451.GJ9619@trillke.net>
	<7be3f35d0808190017w3db68e58rf4970a4c69e444d2@mail.gmail.com>
	<7be3f35d0808190025t473743f4w5cf7affa35715786@mail.gmail.com>
	<20080819085723.GR9619@trillke.net>
Message-ID: <20080819123638.GU9619@trillke.net>

Hi Harald, Ralf, 

so i created an egg with a function that tries to undo 
the path changes done with 0.9.1.  I checked that the
code works but i think that setuptools does not execute
my code at runtime, only at bdist_egg time.  I guess 
i need to investigate how i can have some code executed
at install time.  Anybody has hints? 

best, 

holger

On Tue, Aug 19, 2008 at 10:57 +0200, holger krekel wrote:
> Hi Harald, 
> 
> On Tue, Aug 19, 2008 at 09:25 +0200, Harald Armin Massa wrote:
> > other test results:
> > 
> > ----> py-0.9.2_alpha_7-py2..>
> > 
> > installs flawless.
> > 
> > But: there are a lot of useless things copied to python25\scripts:
> > 
> > py.cleanup.cmd
> > py.countloc.cmd
> > py.lookup.cmd
> > py.rest.cmd
> > py.test.cmd
> > 
> > do not have ANY use on windows, as  windows tries to open "py.cleanup"
> > when typin py.cleanup; which of course fails.
> 
> hum, i think this relates to earlier installs and/or your 
> PATH settings.  the above egg does not install "py.*". 
> What it does is this (see "def run" at the end of 
> http://codespeak.net/svn/py/release/0.9.x/setup.py): 
> rename 
>     py.test, py.rest, etc. to 
>     py_test, py_rest, etc. 
> 
> in the Python25/Scripts dir and create py.test.cmd, py.rest.cmd, ...
> helpers which calls the underscore scripts. 
> 
> But indeed, if one installs 0.9.1 and then 0.9.2-alpha one cannot 
> use "py.test" out of the box.  This relates to the old PATH hacks. 
> The new egg does not need to add to PATH which i think is good.  
> So i guess I am going to work to try to fix things by
> going through the PATH and pruning out "py/bin/" PATHS
> if they look like py lib ones.  Actually i think it
> makes sense to try to undo this PATH addition while
> upgrading, anyway.  
>  
> > Recommendation: rename those to pycleanup.cmd, pycountloc.cmd etc.
> 
> i'd like to have uniforming naming if possible. 
> 
> on two sidenotes, i wonder why setuptools does not automatically 
> delete the old py lib version and if there is a setuptool-supported
> way of uninstalling packages. 
> 
> many thanks for noting this, 
> holger
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

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

From faassen at startifact.com  Tue Aug 19 18:46:55 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Tue, 19 Aug 2008 18:46:55 +0200
Subject: [py-dev] setup.py broken in develop mode on trunk
Message-ID: <g8etdv$vib$1@ger.gmane.org>

Hi there,

In order to see whether a bugfix in Py trunk fixed a bug in my project, 
I tried installing the py trunk as a develop egg (using buildout). It's 
possible "python setup.py develop" is therefore similarly broken.

I see files mentioned in MANIFEST which don't exist, so initially I 
thought this was blocking things. It turns out however that setup.py has 
references to packages which at least don't appear to exist: py.io.test, 
py.test.rsession, py.test.terminal. After I remove those from setup.py 
things seem to work again (that is, I can run the code. I get errors. 
Another mail about those...)

With setuptools, MANIFEST shouldn't be necessary: you can instruct 
setup.py to automatically assume files that are checked into SVN are in 
manifest, with something like this:

from setuptools import find_packages

       package_dir={'': 'src'},
       packages=find_packages('py'),

Regards,

Martijn


From faassen at startifact.com  Tue Aug 19 19:02:34 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Tue, 19 Aug 2008 19:02:34 +0200
Subject: [py-dev] error on trunk in py.path.svn support
Message-ID: <g8eubb$3a5$1@ger.gmane.org>

Hi there,

I just tried the trunk of Py with my project which makes very heavy use 
of the py.path SVN facilities, and I get a lot of errors that look like 
this:

       File 
"/home/faassen/buildout/z3c.vcsync/py/py/path/svn/wccommand.py", line
  270, in status
         rootstatus = XMLWCStatus(self).fromstring(out, self)
       File 
"/home/faassen/buildout/z3c.vcsync/py/py/path/svn/wccommand.py", line
  687, in fromstring
         for c in commitel.getElementsByTagName('author')[0]\
     IndexError: list index out of range

It looks to me like a certain assumption about the format of the XML 
returned is incorrect.

The SVN version on my system is svn, version 1.4.3 (r23084)

When debugging it, the XML that trips up the code looks like this:

<entry path="/tmp/pytest-23/wc">
<wc-status item="normal" props="none" revision="0">
<commit revision="0">
<date>2008-08-19T16:50:53.400198Z</date>
</commit>
</wc-status>
</entry>

It looks like this means there is not always an 'author' entry in this 
XML structure.

Attached is a patch to wccommand.py that makes the problem go away (and 
indeed seems to fix the original problem I was looking into - the trunk 
has support for the svn status flag R, something that py 0.9.1 didn't have).

I realize this patch isn't enough but needs a test as well. I could find 
no obvious way (in the form of documentation, say, the README.txt, or 
the website) on how to actually run the tests of the trunk. :)  It's 
quite possible I missed something.

Is py 0.9.2 to be based off the work on the trunk?

Regards,

Martijn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: authorxml.patch
Type: text/x-patch
Size: 867 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20080819/51707bff/attachment.bin 

From faassen at startifact.com  Tue Aug 19 19:05:30 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Tue, 19 Aug 2008 19:05:30 +0200
Subject: [py-dev] setup.py broken in develop mode on trunk
In-Reply-To: <g8etdv$vib$1@ger.gmane.org>
References: <g8etdv$vib$1@ger.gmane.org>
Message-ID: <g8eugq$3a5$2@ger.gmane.org>

Hi there,

Attached is a hacky patch to setup.py which makes buildout develop mode 
(and quite possibly also "python setup.py develop", but I know buildout 
better) happy for the trunk. I just removed anything that tripped up 
running setup.py.

Regards,

Martijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.patch
Type: text/x-patch
Size: 936 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20080819/fe52f3a4/attachment-0001.bin 

From holger at merlinux.eu  Tue Aug 19 19:39:44 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 19 Aug 2008 19:39:44 +0200
Subject: [py-dev] setup.py broken in develop mode on trunk
In-Reply-To: <g8etdv$vib$1@ger.gmane.org>
References: <g8etdv$vib$1@ger.gmane.org>
Message-ID: <20080819173944.GX9619@trillke.net>

Hi Martijn, 

thanks for noting ... 

On Tue, Aug 19, 2008 at 18:46 +0200, Martijn Faassen wrote:
> In order to see whether a bugfix in Py trunk fixed a bug in my project, 
> I tried installing the py trunk as a develop egg (using buildout). It's 
> possible "python setup.py develop" is therefore similarly broken.
> 
> I see files mentioned in MANIFEST which don't exist, so initially I 
> thought this was blocking things. It turns out however that setup.py has 
> references to packages which at least don't appear to exist: py.io.test, 
> py.test.rsession, py.test.terminal. After I remove those from setup.py 
> things seem to work again (that is, I can run the code. I get errors. 
> Another mail about those...)

... and sorry for the confusion.  Actually the setup.py on
py/trunk resulted from a yesterday merge of release/0.9.x ... 
but i now regenerated the setup.py and MANIFEST files. 

> With setuptools, MANIFEST shouldn't be necessary: you can instruct 
> setup.py to automatically assume files that are checked into SVN are in 
> manifest, with something like this:
> 
> from setuptools import find_packages
> 
>        package_dir={'': 'src'},
>        packages=find_packages('py'),

ok, but for now i'd still like to be compatible to distutils
(a user can just switch a "1" to "0") and i am auto-generating 
the setup.py file so i don't care. 

let me know if the problems persist or things just work. 

holger

From holger at merlinux.eu  Tue Aug 19 19:48:59 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 19 Aug 2008 19:48:59 +0200
Subject: [py-dev] error on trunk in py.path.svn support
In-Reply-To: <g8eubb$3a5$1@ger.gmane.org>
References: <g8eubb$3a5$1@ger.gmane.org>
Message-ID: <20080819174859.GY9619@trillke.net>

Hi Martijn, 

hum, this probably results from Guido's yesterday merge 
of his xmlstatus branch ... 

On Tue, Aug 19, 2008 at 19:02 +0200, Martijn Faassen wrote:
> Hi there,
>
> I just tried the trunk of Py with my project which makes very heavy use  
> of the py.path SVN facilities, and I get a lot of errors that look like  
> this:
>
>       File  
> "/home/faassen/buildout/z3c.vcsync/py/py/path/svn/wccommand.py", line
>  270, in status
>         rootstatus = XMLWCStatus(self).fromstring(out, self)
>       File  
> "/home/faassen/buildout/z3c.vcsync/py/py/path/svn/wccommand.py", line
>  687, in fromstring
>         for c in commitel.getElementsByTagName('author')[0]\
>     IndexError: list index out of range
>
> It looks to me like a certain assumption about the format of the XML  
> returned is incorrect.
>
> The SVN version on my system is svn, version 1.4.3 (r23084)
>
> When debugging it, the XML that trips up the code looks like this:
>
> <entry path="/tmp/pytest-23/wc">
> <wc-status item="normal" props="none" revision="0">
> <commit revision="0">
> <date>2008-08-19T16:50:53.400198Z</date>
> </commit>
> </wc-status>
> </entry>
>
> It looks like this means there is not always an 'author' entry in this  
> XML structure.
>
> Attached is a patch to wccommand.py that makes the problem go away (and  
> indeed seems to fix the original problem I was looking into - the trunk  
> has support for the svn status flag R, something that py 0.9.1 didn't 
> have).
>
> I realize this patch isn't enough but needs a test as well. I could find  
> no obvious way (in the form of documentation, say, the README.txt, or  
> the website) on how to actually run the tests of the trunk. :)  It's  
> quite possible I missed something.
>
> Is py 0.9.2 to be based off the work on the trunk?

yes, 0.9.2 actually mirrors trunk/py/path. 
If you could submit a test and a fix today
or early tomorrow it can definitely go in. 
(i anyway still am fighting with windows installation issues, sight). 

as to the tests: if you have "setup.py develop" 
you should be able to run 

    py.test --runslowtests py/path/svn/testing/test_wccomannd.py 

or even better :)

    py.test -n 3 --runslowtests py/path/svn/testing/test_wccomannd.py 

which doubles test speed on dual-core machines. 

you can add a test there, i guess one that just feeds a
minimal XML string into the method and checks that it groks it
fine. 

oh, and just commit, i'll review the commit (and guido as well, i guess).

thanks & best, 

holger

From johnny at johnnydebris.net  Tue Aug 19 22:04:04 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Tue, 19 Aug 2008 22:04:04 +0200
Subject: [py-dev] error on trunk in py.path.svn support
In-Reply-To: <20080819174859.GY9619@trillke.net>
References: <g8eubb$3a5$1@ger.gmane.org> <20080819174859.GY9619@trillke.net>
Message-ID: <48AB2734.1050603@johnnydebris.net>

holger krekel wrote:
> hum, this probably results from Guido's yesterday merge 
> of his xmlstatus branch ... 
>
>   
Indeed it does... Or did, because I just fixed it by applying Martijn's 
patch, and adding a test. Thanks for reporting, and for the patch, Martijn!

Cheers,

Guido

From schmir at gmail.com  Tue Aug 19 22:33:07 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Tue, 19 Aug 2008 22:33:07 +0200
Subject: [py-dev] setuptools / undoing 0.9.1 PATH hacks (Re: 0.9.2 alpha
	eggs - please test)
In-Reply-To: <20080819123638.GU9619@trillke.net>
References: <20080818135244.GI9619@trillke.net>
	<20080818135451.GJ9619@trillke.net>
	<7be3f35d0808190017w3db68e58rf4970a4c69e444d2@mail.gmail.com>
	<7be3f35d0808190025t473743f4w5cf7affa35715786@mail.gmail.com>
	<20080819085723.GR9619@trillke.net>
	<20080819123638.GU9619@trillke.net>
Message-ID: <932f8baf0808191333h5335af53n2a42add6f9aa1167@mail.gmail.com>

On Tue, Aug 19, 2008 at 2:36 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Harald, Ralf,
>
> so i created an egg with a function that tries to undo
> the path changes done with 0.9.1.  I checked that the
> code works but i think that setuptools does not execute
> my code at runtime, only at bdist_egg time.  I guess
> i need to investigate how i can have some code executed
> at install time.  Anybody has hints?
>

no, sorry.

From faassen at startifact.com  Tue Aug 19 22:52:25 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Tue, 19 Aug 2008 22:52:25 +0200
Subject: [py-dev] error on trunk in py.path.svn support
In-Reply-To: <48AB2734.1050603@johnnydebris.net>
References: <g8eubb$3a5$1@ger.gmane.org> <20080819174859.GY9619@trillke.net>
	<48AB2734.1050603@johnnydebris.net>
Message-ID: <8928d4e90808191352v67f95825w4b490b99487dfbce@mail.gmail.com>

Hey,

Thanks for the test, Guido!

Regards,

Martijn

From holger at merlinux.eu  Tue Aug 19 22:57:37 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 19 Aug 2008 22:57:37 +0200
Subject: [py-dev] error on trunk in py.path.svn support
In-Reply-To: <8928d4e90808191352v67f95825w4b490b99487dfbce@mail.gmail.com>
References: <g8eubb$3a5$1@ger.gmane.org> <20080819174859.GY9619@trillke.net>
	<48AB2734.1050603@johnnydebris.net>
	<8928d4e90808191352v67f95825w4b490b99487dfbce@mail.gmail.com>
Message-ID: <20080819205737.GA9619@trillke.net>

On Tue, Aug 19, 2008 at 22:52 +0200, Martijn Faassen wrote:
> Thanks for the test, Guido!
> 
> Regards,
> 
> Martijn

thanks to both of you, i merged it to 0.9.x

... and i am still thinking about the way
to approach bdist eggs, windows, sdist's
and py.* cmdlines ... there *must* a nice
solution :) 

holger

From faassen at startifact.com  Wed Aug 20 14:52:39 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Wed, 20 Aug 2008 14:52:39 +0200
Subject: [py-dev] error on trunk in py.path.svn support
In-Reply-To: <20080819205737.GA9619@trillke.net>
References: <g8eubb$3a5$1@ger.gmane.org> <20080819174859.GY9619@trillke.net>
	<48AB2734.1050603@johnnydebris.net>
	<8928d4e90808191352v67f95825w4b490b99487dfbce@mail.gmail.com>
	<20080819205737.GA9619@trillke.net>
Message-ID: <8928d4e90808200552v3db5d812s74e2ad1773d0395@mail.gmail.com>

Hi there,

Concerning bdist eggs, don't make them unless something should be
compiled. If you do need a compiler, make them *only* for the Windows
platform.

We went to this pattern for all Zope-related eggs and also with lxml
and it has worked well.

The drawback of binary eggs for any other platform but Windows is that
they tend to break under various circumstances if there is compiled
code (Python might be compiled with 2 or 4 byte unicode support, for
instance). If there *is* no code to compile, the drawback is that the
binary egg locks you into whatever Python versions it has been
released for. A .tgz works just fine as well with the easy_install
tools and buildout and works without them too.

This describes the Zope-related release procedure:

http://grok.zope.org/documentation/how-to/releasing-software

So, the rule:

python setup.py register sdist upload

for any egg unless you have compiled extensions and you're releasing a
Windows egg.

Concerning command-line scripts I'm not sure I can help. I use (I
believe setuptools) support for entry_points:

'console_scripts': {
  'scriptname = foo.bar:mainfunc',
  ]
},

with default easy_install that causes scripts to end up in /usr/bin,
but with buildout, these scripts end up in a 'bin' subdirectory (or
whatever your configuration is) of the buildout direcory (which is by
default the project directory which contains setup.py).

(for other scripts not directly supplied by the package such as for
instance a test runner itself I use various buildout recipes to create
them. I'm not sure whether that's relevant here)

Regards,

Martijn

From schmir at gmail.com  Wed Aug 20 15:27:01 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 20 Aug 2008 15:27:01 +0200
Subject: [py-dev] error on trunk in py.path.svn support
In-Reply-To: <8928d4e90808200552v3db5d812s74e2ad1773d0395@mail.gmail.com>
References: <g8eubb$3a5$1@ger.gmane.org> <20080819174859.GY9619@trillke.net>
	<48AB2734.1050603@johnnydebris.net>
	<8928d4e90808191352v67f95825w4b490b99487dfbce@mail.gmail.com>
	<20080819205737.GA9619@trillke.net>
	<8928d4e90808200552v3db5d812s74e2ad1773d0395@mail.gmail.com>
Message-ID: <932f8baf0808200627v6c12dd26y1d53ad423d744e18@mail.gmail.com>

On Wed, Aug 20, 2008 at 2:52 PM, Martijn Faassen <faassen at startifact.com> wrote:
> Hi there,
>
> Concerning bdist eggs, don't make them unless something should be
> compiled. If you do need a compiler, make them *only* for the Windows
> platform.
>

Isn't it safe to build eggs for OS X? Did you run into problems with that?

Regards,
- Ralf

From faassen at startifact.com  Wed Aug 20 15:48:27 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Wed, 20 Aug 2008 15:48:27 +0200
Subject: [py-dev] error on trunk in py.path.svn support
In-Reply-To: <932f8baf0808200627v6c12dd26y1d53ad423d744e18@mail.gmail.com>
References: <g8eubb$3a5$1@ger.gmane.org> <20080819174859.GY9619@trillke.net>
	<48AB2734.1050603@johnnydebris.net>
	<8928d4e90808191352v67f95825w4b490b99487dfbce@mail.gmail.com>
	<20080819205737.GA9619@trillke.net>
	<8928d4e90808200552v3db5d812s74e2ad1773d0395@mail.gmail.com>
	<932f8baf0808200627v6c12dd26y1d53ad423d744e18@mail.gmail.com>
Message-ID: <8928d4e90808200648u65338db6rc9f24dedcfc9a6ce@mail.gmail.com>

Hi there,

On Wed, Aug 20, 2008 at 3:27 PM, Ralf Schmitt <schmir at gmail.com> wrote:
> On Wed, Aug 20, 2008 at 2:52 PM, Martijn Faassen <faassen at startifact.com> wrote:
>> Concerning bdist eggs, don't make them unless something should be
>> compiled. If you do need a compiler, make them *only* for the Windows
>> platform.
>
> Isn't it safe to build eggs for OS X? Did you run into problems with that?

I don't use OS X as my primary development platform, but people who
*do* use OS X have recommended this practice.

Anyway, I'd expect problems, as from what I've seen of OS X it is very
frequent people install non-system Pythons on it, in a variety of ways
(fink, darwinports, etc).

Regards,

Martijn

From holger at merlinux.eu  Wed Aug 20 19:12:15 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 20 Aug 2008 19:12:15 +0200
Subject: [py-dev] 0.9.2 beta eggs / Windows Notes / API gen pending
Message-ID: <20080820171215.GE9619@trillke.net>

Hi again, 

after i fixed a number of bugs (mostly windows specific) 
and after lots of experimentation i settled for a simpler
approach for setup.py: it's now setuptools only and
uses the "entry_points" hook as Ralf originally suggested
and Martijn now recommended as well.  There is no "_findpy" 
hack anymore. 

i've uploaded the beta to pypi: 

    http://codespeak.net/py/0.9.2/download.html

Note to harald and users who have used py.test and friends
with earlier installs: please read the important note 
and execute the cleanupscript. 

Guido: i think i need some help with API generation - 
that link is currently broken and i guess you know
what is wrong. 

best & cheers, 

holger

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

From fijall at gmail.com  Thu Aug 21 00:09:59 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 21 Aug 2008 00:09:59 +0200
Subject: [py-dev] 0.9.2 beta eggs / Windows Notes / API gen pending
In-Reply-To: <20080820171215.GE9619@trillke.net>
References: <20080820171215.GE9619@trillke.net>
Message-ID: <693bc9ab0808201509l6016ae72icc232d5f1732974e@mail.gmail.com>

I checked out on my linux machine. Stuff seems to work (module my
broken setuptools on some python installations). Will try on more
random machines tomorrow, let's see.

PS. Do we care if it works with pypy-c? Because then there is no need
of invoking C compiler (greenlets are either builtin or not at all)

Cheers,
fijal

On Wed, Aug 20, 2008 at 7:12 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi again,
>
> after i fixed a number of bugs (mostly windows specific)
> and after lots of experimentation i settled for a simpler
> approach for setup.py: it's now setuptools only and
> uses the "entry_points" hook as Ralf originally suggested
> and Martijn now recommended as well.  There is no "_findpy"
> hack anymore.
>
> i've uploaded the beta to pypi:
>
>    http://codespeak.net/py/0.9.2/download.html
>
> Note to harald and users who have used py.test and friends
> with earlier installs: please read the important note
> and execute the cleanupscript.
>
> Guido: i think i need some help with API generation -
> that link is currently broken and i guess you know
> what is wrong.
>
> best & cheers,
>
> holger
>
> --
> collaborative expert contracting: http://merlinux.eu
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> pylib py.test/greenlets/svn APIs: http://pylib.org
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
>

From holger at merlinux.eu  Thu Aug 21 09:10:54 2008
From: holger at merlinux.eu (holger krekel)
Date: Thu, 21 Aug 2008 09:10:54 +0200
Subject: [py-dev] 0.9.2 beta eggs / Windows Notes / API gen pending
In-Reply-To: <693bc9ab0808201509l6016ae72icc232d5f1732974e@mail.gmail.com>
References: <20080820171215.GE9619@trillke.net>
	<693bc9ab0808201509l6016ae72icc232d5f1732974e@mail.gmail.com>
Message-ID: <20080821071054.GG9619@trillke.net>

On Thu, Aug 21, 2008 at 00:09 +0200, Maciej Fijalkowski wrote:
> I checked out on my linux machine. Stuff seems to work (module my
> broken setuptools on some python installations). Will try on more
> random machines tomorrow, let's see.
> 
> PS. Do we care if it works with pypy-c? Because then there is no need
> of invoking C compiler (greenlets are either builtin or not at all)

i expect things to work - but in any case let's see that
pypy-1.1 and py lib 1.0 work well together. 

holger

> On Wed, Aug 20, 2008 at 7:12 PM, holger krekel <holger at merlinux.eu> wrote:
> > Hi again,
> >
> > after i fixed a number of bugs (mostly windows specific)
> > and after lots of experimentation i settled for a simpler
> > approach for setup.py: it's now setuptools only and
> > uses the "entry_points" hook as Ralf originally suggested
> > and Martijn now recommended as well.  There is no "_findpy"
> > hack anymore.
> >
> > i've uploaded the beta to pypi:
> >
> >    http://codespeak.net/py/0.9.2/download.html
> >
> > Note to harald and users who have used py.test and friends
> > with earlier installs: please read the important note
> > and execute the cleanupscript.
> >
> > Guido: i think i need some help with API generation -
> > that link is currently broken and i guess you know
> > what is wrong.
> >
> > best & cheers,
> >
> > holger
> >
> > --
> > collaborative expert contracting: http://merlinux.eu
> > PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> > pylib py.test/greenlets/svn APIs: http://pylib.org
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> >
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

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

From holger at merlinux.eu  Thu Aug 21 10:30:58 2008
From: holger at merlinux.eu (holger krekel)
Date: Thu, 21 Aug 2008 10:30:58 +0200
Subject: [py-dev] error on trunk in py.path.svn support
In-Reply-To: <8928d4e90808200552v3db5d812s74e2ad1773d0395@mail.gmail.com>
References: <g8eubb$3a5$1@ger.gmane.org> <20080819174859.GY9619@trillke.net>
	<48AB2734.1050603@johnnydebris.net>
	<8928d4e90808191352v67f95825w4b490b99487dfbce@mail.gmail.com>
	<20080819205737.GA9619@trillke.net>
	<8928d4e90808200552v3db5d812s74e2ad1773d0395@mail.gmail.com>
Message-ID: <20080821083058.GI9619@trillke.net>

Hi Martijn, 

On Wed, Aug 20, 2008 at 14:52 +0200, Martijn Faassen wrote:
> Concerning bdist eggs, don't make them unless something should be
> compiled. If you do need a compiler, make them *only* for the Windows
> platform.
> 
> We went to this pattern for all Zope-related eggs and also with lxml
> and it has worked well.

yip, i am using that as well. 
 
> The drawback of binary eggs for any other platform but Windows is that
> they tend to break under various circumstances if there is compiled
> code (Python might be compiled with 2 or 4 byte unicode support, for
> instance). If there *is* no code to compile, the drawback is that the
> binary egg locks you into whatever Python versions it has been
> released for. A .tgz works just fine as well with the easy_install
> tools and buildout and works without them too.
>
> This describes the Zope-related release procedure:
> 
> http://grok.zope.org/documentation/how-to/releasing-software

thanks, nice doc.  

> So, the rule:
> 
> python setup.py register sdist upload
> 
> for any egg unless you have compiled extensions and you're releasing a
> Windows egg.

ok.  py lib has the greenlet extension so this requires
bdist_egg from windows. 

so, now i am trying to also get "easy_install py==dev" to work.  
I tried having a setup.cfg of

    [egg_info]
    tag_build = .dev
    tag_svn_revision = 1

and with a "version=1.0.0.a1" in setup.py and calling 

    python setup.py sdist upload

this registered and uploaded a 1.0.0a1-r57529 version fine. 

But then "easy_install py" on another machine gave me the dev
version instead of the release (0.9.2b7 currently).  
What am i missing? 
(i removed the 1.0.0a1 completely from pypi, btw).  

> Concerning command-line scripts I'm not sure I can help. I use (I
> believe setuptools) support for entry_points:
> 
> 'console_scripts': {
>   'scriptname = foo.bar:mainfunc',
>   ]
> },

py lib is using that as well now.  

> with default easy_install that causes scripts to end up in /usr/bin,
> but with buildout, these scripts end up in a 'bin' subdirectory (or
> whatever your configuration is) of the buildout direcory (which is by
> default the project directory which contains setup.py).

yip, same with virtualenv. 

> (for other scripts not directly supplied by the package such as for
> instance a test runner itself I use various buildout recipes to create
> them. I'm not sure whether that's relevant here)

i guess i am still learning how to deal conveniently with
setuptools ... 
holger

From faassen at startifact.com  Thu Aug 21 14:31:19 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 21 Aug 2008 14:31:19 +0200
Subject: [py-dev] error on trunk in py.path.svn support
In-Reply-To: <20080821083058.GI9619@trillke.net>
References: <g8eubb$3a5$1@ger.gmane.org> <20080819174859.GY9619@trillke.net>
	<48AB2734.1050603@johnnydebris.net>
	<8928d4e90808191352v67f95825w4b490b99487dfbce@mail.gmail.com>
	<20080819205737.GA9619@trillke.net>
	<8928d4e90808200552v3db5d812s74e2ad1773d0395@mail.gmail.com>
	<20080821083058.GI9619@trillke.net>
Message-ID: <8928d4e90808210531w3fc3848dnc4c4116aa806d3c4@mail.gmail.com>

Hi there,

[snip]
> so, now i am trying to also get "easy_install py==dev" to work.
> I tried having a setup.cfg of
>
>    [egg_info]
>    tag_build = .dev
>    tag_svn_revision = 1
>
> and with a "version=1.0.0.a1" in setup.py and calling
>
>    python setup.py sdist upload
>
> this registered and uploaded a 1.0.0a1-r57529 version fine.

Ugly. In the Zope community we've been avoiding any setup.cfg and
we've done actual proper releases whenever needed. We used to produce
a lot of those ugly -r515153 eggs, but for a large system composed out
of multiple packages such a "release but not really a proper release"
things were far more pain than they're worth, as the releases didn't
tend to be very well managed.

> But then "easy_install py" on another machine gave me the dev
> version instead of the release (0.9.2b7 currently).
> What am i missing?

Hm, I don't know off the top of my head, I'm afraid.

> (i removed the 1.0.0a1 completely from pypi, btw).

Removing released eggs is also not a good idea to do very often. We
have a policy that we never remove anything from PyPI but just make a
new, later, release. People may be depending on the versions on PyPI -
automatic build systems may pull in an egg before you know it, after
all.

I'm just sketching out what I know from our Zope egg release mill
here. Other approaches may of course work too, I'm just telling you
what works for us (and the bits I know).

Regards,

Martijn

From holger at merlinux.eu  Fri Aug 22 13:21:46 2008
From: holger at merlinux.eu (holger krekel)
Date: Fri, 22 Aug 2008 13:21:46 +0200
Subject: [py-dev] 0.9.2 is out
Message-ID: <20080822112146.GR9619@trillke.net>

Hi, thanks to all who helped with the 0.9.2 release!
see below for the release announcement.  hope that
all the eggs now work properly.  cheers, holger


Welcome to the 0.9.2 py lib and py.test release -
mainly fixing Windows issues, providing better
packaging and integration with setuptools.

Summry of main features:

* py.test: cross-project testing tool with many advanced features
* py.execnet: ad-hoc code distribution to SSH, Socket and local sub processes
* py.magic.greenlet: micro-threads on standard CPython ("stackless-light")
* py.path: path abstractions over local and subversion files
* rich documentation of py's exported API
* tested against Linux, Win32, OSX, works on python 2.3-2.6

good entry points: 

Pypi pages: http://pypi.python.org/pypi/py/
Download/Install: http://codespeak.net/py/0.9.2/download.html
Documentation/API:  http://codespeak.net/py/0.9.2/index.html

the CHANGELOG excerpt for the 0.9.1 -> 0.9.2 transition: 

* refined installation and metadata, created new setup.py, 
  now based on setuptools/ez_setup (thanks to Ralf Schmitt 
  for his support).

* improved the way of making py.* scripts available in 
  windows environments, they are now added to the 
  Scripts directory as ".cmd" files. 

* py.path.svnwc.status() now is more complete and 
  uses xml output from the 'svn' command if available
  (Guido Wesdorp)

* fix for py.path.svn* to work with svn 1.5
  (Chris Lamb)

* fix path.relto(otherpath) method on windows to 
  use normcase for checking if a path is relative.

* py.test's traceback is better parseable from editors 
  (follows the filenames:LINENO: MSG convention)
  (thanks to Osmo Salomaa)

* fix to javascript-generation, "py.test --runbrowser" 
  should work more reliably now

* removed previously accidentally added 
  py.test.broken and py.test.notimplemented helpers. 

* there now is a py.__version__ attribute


best and have fun,

holger krekel

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

From Jim.Vickroy at noaa.gov  Thu Aug 28 23:09:20 2008
From: Jim.Vickroy at noaa.gov (Jim Vickroy)
Date: Thu, 28 Aug 2008 15:09:20 -0600
Subject: [py-dev] 0.9.2 is out
In-Reply-To: <20080822112146.GR9619@trillke.net>
References: <20080822112146.GR9619@trillke.net>
Message-ID: <48B71400.4000403@noaa.gov>

holger krekel wrote:
> Hi, thanks to all who helped with the 0.9.2 release!
> see below for the release announcement.  hope that
> all the eggs now work properly.  cheers, holger
>
>
> Welcome to the 0.9.2 py lib and py.test release -
> mainly fixing Windows issues, providing better
> packaging and integration with setuptools.
>
> Summry of main features:
>
> * py.test: cross-project testing tool with many advanced features
> * py.execnet: ad-hoc code distribution to SSH, Socket and local sub processes
> * py.magic.greenlet: micro-threads on standard CPython ("stackless-light")
> * py.path: path abstractions over local and subversion files
> * rich documentation of py's exported API
> * tested against Linux, Win32, OSX, works on python 2.3-2.6
>
> good entry points: 
>
> Pypi pages: http://pypi.python.org/pypi/py/
> Download/Install: http://codespeak.net/py/0.9.2/download.html
> Documentation/API:  http://codespeak.net/py/0.9.2/index.html
>
>   
[... snip ...]

I attempted to upgrade from py 0.9.1 to 0.9.2 on my fully-patched, MS 
Windows XP  Pro machine running Python 2.5.2, but I do not think I was 
successful.

Following the recommendation at 
http://codespeak.net/py/0.9.2/download.html, I downloaded and ran the 
cleanup script.  Here is the output:

C:\>py-winpath-clean.py

PATH contains old py/bin/win32 scripts: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\Common Files\Adaptec Shared\System;C:\Python25;C:\Python25\DLLS;C:\Python25\Lib\s

ite-packages;C:\Program Files\Microsoft Visual Studio\VSS;C:\Program Files\Microsoft SQL Server\80\Tools\BINN;c:\PAGE;C:\Program Files\Multi-Edit 9;C:\Program Files\NSIS;C:\RSI\IDL55\bin\bin.x86;C:\Py

thon25\Lib\site-packages\py\bin\win32;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Intel\DMIX;C:\Python25\Lib\site-packages\py\bin\win32

pruning and setting a new PATH: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\Common Files\Adaptec Shared\System;C:\Python25;C:\Python25\DLLS;C:\Python25\Lib\site-pack

ages;C:\Program Files\Microsoft Visual Studio\VSS;C:\Program Files\Microsoft SQL Server\80\Tools\BINN;c:\PAGE;C:\Program Files\Multi-Edit 9;C:\Program Files\NSIS;C:\RSI\IDL55\bin\bin.x86;C:\Program Fi

les\QuickTime\QTSystem\;C:\Program Files\Intel\DMIX

removing C:\Python25\scripts\py.test

removing C:\Python25\scripts\py.lookup

removing C:\Python25\scripts\py.cleanup

removing C:\Python25\scripts\py.rest

removing C:\Python25\scripts\py.countloc

removing C:\Python25\scripts\_update_website.py

removing C:\Python25\scripts\_makepyrelease.py

removing C:\Python25\scripts\_findpy.py

removing C:\Python25\scripts\pytest.cmd


Here is my attempt to install py 0.9.2 ...

C:\>easy_install py

Searching for py

Best match: py 0.9.1

Adding py 0.9.1 to easy-install.pth file

Using c:\python25\lib\site-packages

Processing dependencies for py

Finished processing dependencies for py

C:\>


... which looks like the same version I already had was reinstalled.

Could someone provide some guidance on what I did incorrectly?

Thanks,
-- jv

From cfbolz at gmx.de  Thu Aug 28 23:13:57 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 28 Aug 2008 23:13:57 +0200
Subject: [py-dev] 0.9.2 is out
In-Reply-To: <48B71400.4000403@noaa.gov>
References: <20080822112146.GR9619@trillke.net> <48B71400.4000403@noaa.gov>
Message-ID: <48B71515.4000104@gmx.de>

Jim Vickroy wrote:
[snip]
> 
> I attempted to upgrade from py 0.9.1 to 0.9.2 on my fully-patched, MS 
> Windows XP  Pro machine running Python 2.5.2, but I do not think I was 
> successful.
> 
> Following the recommendation at 
> http://codespeak.net/py/0.9.2/download.html, I downloaded and ran the 
> cleanup script.  Here is the output:
> 
[snip]
> 
> 
> Here is my attempt to install py 0.9.2 ...
> 
> C:\>easy_install py
> 
> Searching for py
> 
> Best match: py 0.9.1
> 
> Adding py 0.9.1 to easy-install.pth file
> 
> Using c:\python25\lib\site-packages
> 
> Processing dependencies for py
> 
> Finished processing dependencies for py
> 
> C:\>
> 
> 
> ... which looks like the same version I already had was reinstalled.
> 
> Could someone provide some guidance on what I did incorrectly?

Maybe you did nothing wrong :-). I Actually observe exactly the same
behavior on my Ubuntu machine, so somehow easy_install does not seem to
pick up 0.9.2?

Cheers,

Carl Friedrich

From pedronis at openend.se  Fri Aug 29 09:57:28 2008
From: pedronis at openend.se (Samuele Pedroni)
Date: Fri, 29 Aug 2008 09:57:28 +0200
Subject: [py-dev] 0.9.2 is out
In-Reply-To: <48B71515.4000104@gmx.de>
References: <20080822112146.GR9619@trillke.net> <48B71400.4000403@noaa.gov>
	<48B71515.4000104@gmx.de>
Message-ID: <48B7ABE8.6000302@openend.se>

Carl Friedrich Bolz wrote:
> Jim Vickroy wrote:
> [snip]
>   
>> I attempted to upgrade from py 0.9.1 to 0.9.2 on my fully-patched, MS 
>> Windows XP  Pro machine running Python 2.5.2, but I do not think I was 
>> successful.
>>
>> Following the recommendation at 
>> http://codespeak.net/py/0.9.2/download.html, I downloaded and ran the 
>> cleanup script.  Here is the output:
>>
>>     
> [snip]
>   
>> Here is my attempt to install py 0.9.2 ...
>>
>> C:\>easy_install py
>>
>> Searching for py
>>
>> Best match: py 0.9.1
>>
>> Adding py 0.9.1 to easy-install.pth file
>>
>> Using c:\python25\lib\site-packages
>>
>> Processing dependencies for py
>>
>> Finished processing dependencies for py
>>
>> C:\>
>>
>>
>> ... which looks like the same version I already had was reinstalled.
>>
>> Could someone provide some guidance on what I did incorrectly?
>>     
>
> Maybe you did nothing wrong :-). I Actually observe exactly the same
> behavior on my Ubuntu machine, so somehow easy_install does not seem to
> pick up 0.9.2?
>   
you need to ask explicitly for an upgrade I think (--upgrade or -U)

From cfbolz at gmx.de  Fri Aug 29 10:47:50 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Fri, 29 Aug 2008 10:47:50 +0200
Subject: [py-dev] 0.9.2 is out
In-Reply-To: <48B7ABE8.6000302@openend.se>
References: <20080822112146.GR9619@trillke.net> <48B71400.4000403@noaa.gov>
	<48B71515.4000104@gmx.de> <48B7ABE8.6000302@openend.se>
Message-ID: <48B7B7B6.8030703@gmx.de>

Samuele Pedroni wrote:
> Carl Friedrich Bolz wrote:
>> Maybe you did nothing wrong :-). I Actually observe exactly the same
>> behavior on my Ubuntu machine, so somehow easy_install does not seem to
>> pick up 0.9.2?
>>   
> you need to ask explicitly for an upgrade I think (--upgrade or -U)

It works! The wonders of extremely advanced technology. Thanks, Samuele.

Cheers,

Carl Friedrich


From holger at merlinux.eu  Fri Aug 29 21:02:25 2008
From: holger at merlinux.eu (holger krekel)
Date: Fri, 29 Aug 2008 21:02:25 +0200
Subject: [py-dev] 0.9.2 is out
In-Reply-To: <48B71400.4000403@noaa.gov>
References: <20080822112146.GR9619@trillke.net> <48B71400.4000403@noaa.gov>
Message-ID: <20080829190225.GE9619@trillke.net>

On Thu, Aug 28, 2008 at 15:09 -0600, Jim Vickroy wrote:
> I attempted to upgrade from py 0.9.1 to 0.9.2 on my fully-patched, MS 
> Windows XP  Pro machine running Python 2.5.2, but I do not think I was 
> successful.
> 
> Following the recommendation at 
> http://codespeak.net/py/0.9.2/download.html, I downloaded and ran the 
> cleanup script.  Here is the output:
> 
> C:\>py-winpath-clean.py
> 
> PATH contains old py/bin/win32 scripts: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\Common Files\Adaptec Shared\System;C:\Python25;C:\Python25\DLLS;C:\Python25\Lib\s
> 
> ite-packages;C:\Program Files\Microsoft Visual Studio\VSS;C:\Program Files\Microsoft SQL Server\80\Tools\BINN;c:\PAGE;C:\Program Files\Multi-Edit 9;C:\Program Files\NSIS;C:\RSI\IDL55\bin\bin.x86;C:\Py
> 
> thon25\Lib\site-packages\py\bin\win32;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Intel\DMIX;C:\Python25\Lib\site-packages\py\bin\win32
> 
> pruning and setting a new PATH: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\Common Files\Adaptec Shared\System;C:\Python25;C:\Python25\DLLS;C:\Python25\Lib\site-pack
> 
> ages;C:\Program Files\Microsoft Visual Studio\VSS;C:\Program Files\Microsoft SQL Server\80\Tools\BINN;c:\PAGE;C:\Program Files\Multi-Edit 9;C:\Program Files\NSIS;C:\RSI\IDL55\bin\bin.x86;C:\Program Fi
> 
> les\QuickTime\QTSystem\;C:\Program Files\Intel\DMIX
> 
> removing C:\Python25\scripts\py.test
> 
> removing C:\Python25\scripts\py.lookup
> 
> removing C:\Python25\scripts\py.cleanup
> 
> removing C:\Python25\scripts\py.rest
> 
> removing C:\Python25\scripts\py.countloc
> 
> removing C:\Python25\scripts\_update_website.py
> 
> removing C:\Python25\scripts\_makepyrelease.py
> 
> removing C:\Python25\scripts\_findpy.py
> 
> removing C:\Python25\scripts\pytest.cmd

this look good :) 
 
> Here is my attempt to install py 0.9.2 ...
> 
> C:\>easy_install py
> 
> Searching for py
> 
> Best match: py 0.9.1
> 
> Adding py 0.9.1 to easy-install.pth file

the others correctly pointed to "-U" already. 
I just updated the web pages to include this switch
by default. Thanks for reporting the issue and let
us know if there are any more problems. 

holger

From holger at merlinux.eu  Wed Sep  3 16:33:46 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 3 Sep 2008 16:33:46 +0200
Subject: [py-dev] showing tracebacks / failure handling (was:
	Re:	[arigo@codespeak.net: [py-svn] r57790 - in py/trunk/py:
	code test	test/report test/report/testing]
In-Reply-To: <20080903101008.GA5776@code0.codespeak.net>
References: <20080903083052.GT9619@trillke.net>
	<20080903101008.GA5776@code0.codespeak.net>
Message-ID: <20080903143346.GW9619@trillke.net>

Hi Armin, (CC to py-dev)

On Wed, Sep 03, 2008 at 12:10 +0200, Armin Rigo wrote:
> Hi Holger,
> 
> On Wed, Sep 03, 2008 at 10:30:53AM +0200, holger krekel wrote:
> > i think the/a test should go to 
> >     
> >     py/code/testing/test_excinfo.py:430 
> 
> True, I can add a test there.  But I had to change a few small things in
> py/test/ too, so the existing test should not be removed.

ok let's have both. 
 
> > also, i wonder if "tb=crash" would be useful so that only the
> > crashing function is shown. 
> 
> Not for me.  I don't use tb=short very often, but when I use it it's for
> cases where PyPy tests spew tracebacks with a hundred entries.  I use
> tb=no a lot though.

do you mean a few hundred failures?  If you mean one failure with 
a few hundred entries than tb=crash would just show one entry.
maybe we better sort this out on IRC :) 
 
> One thing I'm really missing from the trunk py.test output is the name
> of the failing tests.  I know it's often the name of the first function
> in the traceback but this is not always reliable (e.g. with generated
> code or broken .pyc files).  My use case here is again PyPy: often, you
> have 5 failures that each spew a lot of stdout and a long traceback.
> Figuring out which 5 tests failed takes quite a while.  In my
> rxvt-terminal-only conftest, I can double-click on the final line that
> says "5 failures" and see a list of the names of the failing tests.  In
> my opinion it would even be useful to always list these names in the
> final line, e.g. looking like:
> 
>     ============= 2 failures: test_foo, test_bar ===============

names are usually much longer, particularly if you include
class and module name. 
 
> with something reasonable if there are too many failures, e.g.:
> 
>     ====== 17 failures: test_foo, test_bar, test_baz, ... ======
> 
> the point being that it's easy to re-run "py.test -k test_foo" to
> reproduce just the first failure, which is often the most relevant one,
> without having to use "py.test -x" which can take a long time to run
> before it hits the failure.

i see the point.   

hum, we could show a summary (by default or through option)
after the tracebacks similar to what you you see with
"--verbose", e.g.

    with curdir=py/doc/ and
    py.test --verbose pytest/failure_demo.py

you currently get

    pytest/failure_demo.py:15: TestFailing.test_simple FAIL
    pytest/failure_demo.py:23:
TestFailing.test_simple_multiline FAIL
    pytest/failure_demo.py:28: TestFailing.test_not FAIL
    pytest/failure_demo.py:33: TestFailing.test_complex_error
FAIL
    pytest/failure_demo.py:40:
TestFailing.test_z1_unpack_error FAIL
    pytest/failure_demo.py:44: TestFailing.test_z2_type_error
FAIL
    ...

But a more fundamental solution is to have py.test store info
about the last test run (by option and/or some ENV variable)
and have options/ways to show and run the last failing tests. 
The latter is also what we want for the new htmlconftest 
so i suggest we maybe first concentrate on this. 

in any case i'd be grateful if you put/copied your hacks
around py.test to directories in contrib (maybe with at 
least one functional test)  so that it'seasier to work
toegether and ensure that things work after refactorings. 

best & thanks,

holger

From arigo at tunes.org  Wed Sep  3 19:04:44 2008
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 3 Sep 2008 19:04:44 +0200
Subject: [py-dev] showing tracebacks / failure handling (was: Re:
	[arigo@codespeak.net: [py-svn] r57790 - in py/trunk/py: code
	test test/report test/report/testing]
In-Reply-To: <20080903143346.GW9619@trillke.net>
References: <20080903083052.GT9619@trillke.net>
	<20080903101008.GA5776@code0.codespeak.net>
	<20080903143346.GW9619@trillke.net>
Message-ID: <20080903170442.GA14244@code0.codespeak.net>

Hi Holger,

On Wed, Sep 03, 2008 at 04:33:46PM +0200, holger krekel wrote:
> in any case i'd be grateful if you put/copied your hacks
> around py.test to directories in contrib (maybe with at 
> least one functional test)  so that it'seasier to work
> toegether and ensure that things work after refactorings. 

My conftest monkey-patches completely internal details around, so
keeping it working would just prevent any refactoring.  I'm ok with
having to throw my conftest mostly away and start again from scratch
after a big refactoring.


A bientot,

Armin.

From holger at merlinux.eu  Wed Sep  3 19:37:50 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 3 Sep 2008 19:37:50 +0200
Subject: [py-dev] showing tracebacks / failure handling (was:
	Re:	[arigo@codespeak.net: [py-svn] r57790 - in py/trunk/py:
	code test	test/report test/report/testing]
In-Reply-To: <20080903170442.GA14244@code0.codespeak.net>
References: <20080903083052.GT9619@trillke.net>
	<20080903101008.GA5776@code0.codespeak.net>
	<20080903143346.GW9619@trillke.net>
	<20080903170442.GA14244@code0.codespeak.net>
Message-ID: <20080903173750.GY9619@trillke.net>

Hi Armin,

On Wed, Sep 03, 2008 at 19:04 +0200, Armin Rigo wrote:
> Hi Holger,
> 
> On Wed, Sep 03, 2008 at 04:33:46PM +0200, holger krekel wrote:
> > in any case i'd be grateful if you put/copied your hacks
> > around py.test to directories in contrib (maybe with at 
> > least one functional test)  so that it'seasier to work
> > toegether and ensure that things work after refactorings. 
> 
> My conftest monkey-patches completely internal details around, so
> keeping it working would just prevent any refactoring.  I'm ok with
> having to throw my conftest mostly away and start again from scratch
> after a big refactoring.

well, i regard your rxvt and particularly your htmlconftest
hacks as valid extensions and would like to improve py.test
such that you do not need to patch internal details.  

holger

From orestis at orestis.gr  Sat Sep 20 23:59:19 2008
From: orestis at orestis.gr (Orestis Markou)
Date: Sat, 20 Sep 2008 22:59:19 +0100
Subject: [py-dev] Information for unittest refugees
Message-ID: <29839E33-8487-4E44-B133-6E76877CF4ED@orestis.gr>

After attending Holger's talk at PyCon UK about py.test, I decided to  
try it out. I'm using a recent svn checkout.

I had a bunch of tests (around 50 of them), all inheriting from  
unittest. I expected that they would work out of the box with py.test,  
and was surprised when they weren't. I tried adding the py_unittest  
conftest.py file to my project, but I got this traceback:

Traceback (most recent call last):
   File "/opt/local/Library/Frameworks/Python.framework/Versions/ 
Current/bin/py.test", line 8, in <module>
     load_entry_point('py==1.0.0a1', 'console_scripts', 'py.test')()
   File "/Users/orestis/Developer/pylib/py/cmdline/pytest.py", line 5,  
in main
     py.test.cmdline.main()
   File "/Users/orestis/Developer/pylib/py/test/cmdline.py", line 12,  
in main
     config.parse(args)
   File "/Users/orestis/Developer/pylib/py/test/config.py", line 46,  
in parse
     self._conftest.setinitial(args)
   File "/Users/orestis/Developer/pylib/py/test/conftesthandle.py",  
line 30, in setinitial
     self._path2confmods[None] = self.getconftestmodules(anchor)
   File "/Users/orestis/Developer/pylib/py/test/conftesthandle.py",  
line 44, in getconftestmodules
     clist.append(importconfig(conftestpath))
   File "/Users/orestis/Developer/pylib/py/test/conftesthandle.py",  
line 74, in importconfig
     mod = configpath.pyimport()
   File "/Users/orestis/Developer/pylib/py/path/local/local.py", line  
413, in pyimport
     mod = __import__(modname, None, None, ['__doc__'])
   File "/Users/orestis/Developer/pysmell/conftest.py", line 52, in  
<module>
     class UnitTestFunction(py.__.test.item.Function):
AttributeError: 'module' object has no attribute 'item'

I expected that the naming conventions would be enough, but I was  
surprised again by the fact that py.test requires "test_" methods  
rather than just "test" methods. Fixing that, I was again surprised  
that my tests still weren't running, and after some guesswork realized  
that the class they were in didn't start with "Test".

I suggest that you add this crucial information in a more clear way  
(it is there, but not very discoverable) or even better, integrate the  
py_unittest collection into py.test - this way people can try out  
their old tests with py.test, rather than having to convert everything.

Best regards,
Orestis Markou
--
orestis at orestis.gr
http://orestis.gr/





From simon at arrowtheory.com  Sun Sep 21 00:29:56 2008
From: simon at arrowtheory.com (Simon Burton)
Date: Sat, 20 Sep 2008 18:29:56 -0400
Subject: [py-dev] py.test problem
Message-ID: <20080920182956.934c637d.simon@arrowtheory.com>


I have hit this problem several times, when an assertion fails using py.test i get

AttributeError:   << 'frame' object has no attribute 'eval'

with no stack trace of where in py.test this occured. (only the stack trace of my test code).

Any ideas ?

It looks like it has something to do with the magic that prints out the values of expressions
in the assertion.

I just did svn up on my py.test, it did not help.

Simon.

From holger at merlinux.eu  Sun Sep 21 08:23:40 2008
From: holger at merlinux.eu (holger krekel)
Date: Sun, 21 Sep 2008 08:23:40 +0200
Subject: [py-dev] py.test problem
In-Reply-To: <20080920182956.934c637d.simon@arrowtheory.com>
References: <20080920182956.934c637d.simon@arrowtheory.com>
Message-ID: <20080921062340.GA22099@trillke.net>

Hi Simon, 

On Sat, Sep 20, 2008 at 18:29 -0400, Simon Burton wrote:
> I have hit this problem several times, when an assertion fails using py.test i get
> 
> AttributeError:   << 'frame' object has no attribute 'eval'
> 
> with no stack trace of where in py.test this occured. (only the stack trace of my test code).
> 
> Any ideas ?

hum, can't remember seeing this one.  Do you have an example? 
If not can you attach a traceback next time? 
 
> It looks like it has something to do with the magic that prints out the values of expressions
> in the assertion.

You can use --nomagic to turn it off. 
 
> I just did svn up on my py.test, it did not help.

that was 'dist'?  svn/py/trunk has a lot of cleaned up code
which might help remedy the problem.

sorry that i can't be more immediately helpful, 
thanks, 
holger

From holger at merlinux.eu  Sun Sep 21 10:23:56 2008
From: holger at merlinux.eu (holger krekel)
Date: Sun, 21 Sep 2008 10:23:56 +0200
Subject: [py-dev] Information for unittest refugees
In-Reply-To: <29839E33-8487-4E44-B133-6E76877CF4ED@orestis.gr>
References: <29839E33-8487-4E44-B133-6E76877CF4ED@orestis.gr>
Message-ID: <20080921082356.GB22099@trillke.net>

Hi Orestis,

thanks for your mail and sorry for the hassle - to be honest 
i haven't cared much for integrating unittests myself yet.  
But i try to improve now :) 

On Sat, Sep 20, 2008 at 22:59 +0100, Orestis Markou wrote:
> After attending Holger's talk at PyCon UK about py.test, I decided to  
> try it out. I'm using a recent svn checkout.
>
> I had a bunch of tests (around 50 of them), all inheriting from  
> unittest. I expected that they would work out of the box with py.test,  
> and was surprised when they weren't. I tried adding the py_unittest  
> conftest.py file to my project, but I got this traceback:
> 
> Traceback (most recent call last):
>    File "/opt/local/Library/Frameworks/Python.framework/Versions/ 
> Current/bin/py.test", line 8, in <module>
>      load_entry_point('py==1.0.0a1', 'console_scripts', 'py.test')()
>    File "/Users/orestis/Developer/pylib/py/cmdline/pytest.py", line 5,  
> in main
>      py.test.cmdline.main()
>    File "/Users/orestis/Developer/pylib/py/test/cmdline.py", line 12,  
> in main
>      config.parse(args)
>    File "/Users/orestis/Developer/pylib/py/test/config.py", line 46,  
> in parse
>      self._conftest.setinitial(args)
>    File "/Users/orestis/Developer/pylib/py/test/conftesthandle.py",  
> line 30, in setinitial
>      self._path2confmods[None] = self.getconftestmodules(anchor)
>    File "/Users/orestis/Developer/pylib/py/test/conftesthandle.py",  
> line 44, in getconftestmodules
>      clist.append(importconfig(conftestpath))
>    File "/Users/orestis/Developer/pylib/py/test/conftesthandle.py",  
> line 74, in importconfig
>      mod = configpath.pyimport()
>    File "/Users/orestis/Developer/pylib/py/path/local/local.py", line  
> 413, in pyimport
>      mod = __import__(modname, None, None, ['__doc__'])
>    File "/Users/orestis/Developer/pysmell/conftest.py", line 52, in  
> <module>
>      class UnitTestFunction(py.__.test.item.Function):
> AttributeError: 'module' object has no attribute 'item'

i think this is a mismatch between the py lib checkout and 
the conftest.  If you checkout 

    http://codespeak.net/svn/py/trunk

* install it e.g. by doing "python setup.py develop" and 
* put contrib/py_unittest/conftest.py into pysmell

then it should work fine now. I actually just tested
with your current GIT version and all but two tests fail
(they look like expected failures). 

> I expected that the naming conventions would be enough, but I was  
> surprised again by the fact that py.test requires "test_" methods  
> rather than just "test" methods. Fixing that, I was again surprised  
> that my tests still weren't running, and after some guesswork realized  
> that the class they were in didn't start with "Test".

hum, methods/functions only need to start with "test" in any case.  
If not there is a bug and i am happy about an example. 

unittest-collected classes don't need to follow a naming
convention - they just need to subclass TestCase as usual. 

py.test-collected classes indeed need to start with "Test". 

So i am a bit confused what your exact problem actually was
here.  Btw, for debugging, "py.test --collectonly" is helpful. 

> I suggest that you add this crucial information in a more clear way  
> (it is there, but not very discoverable) or even better, integrate the  
> py_unittest collection into py.test - this way people can try out  
> their old tests with py.test, rather than having to convert everything.

good point.  So far i was hesitant with promoting it 
because i wanted to spend a bit more time into docs and 
an infrastructure that helps with checking that things 
are consistent.  It apparently gets about time now :) 

best, 
holger

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

From orestis at orestis.gr  Sun Sep 21 12:41:39 2008
From: orestis at orestis.gr (Orestis Markou)
Date: Sun, 21 Sep 2008 11:41:39 +0100
Subject: [py-dev] Information for unittest refugees
In-Reply-To: <20080921082356.GB22099@trillke.net>
References: <29839E33-8487-4E44-B133-6E76877CF4ED@orestis.gr>
	<20080921082356.GB22099@trillke.net>
Message-ID: <158DF2B2-FE29-47AA-9F21-F2CB8E247941@orestis.gr>

> i think this is a mismatch between the py lib checkout and
> the conftest.  If you checkout
>
>    http://codespeak.net/svn/py/trunk
>
> * install it e.g. by doing "python setup.py develop" and
> * put contrib/py_unittest/conftest.py into pysmell
>
> then it should work fine now. I actually just tested
> with your current GIT version and all but two tests fail
> (they look like expected failures).
>

Ah, I was following your slides and checkout out the py_unittest  
directory directly - copying contrib/py_unittest/conftest.py worked!


>> I expected that the naming conventions would be enough, but I was
>> surprised again by the fact that py.test requires "test_" methods
>> rather than just "test" methods. Fixing that, I was again surprised
>> that my tests still weren't running, and after some guesswork  
>> realized
>> that the class they were in didn't start with "Test".
>
> hum, methods/functions only need to start with "test" in any case.
> If not there is a bug and i am happy about an example.

Sorry, I was confused because I didn't prepend Test to my classes.  
Indeed no underscore was needed.
>
>
> unittest-collected classes don't need to follow a naming
> convention - they just need to subclass TestCase as usual.
>
> py.test-collected classes indeed need to start with "Test".
>
> So i am a bit confused what your exact problem actually was
> here.  Btw, for debugging, "py.test --collectonly" is helpful.

My problem was that I had a lot of test_* methods in a class that  
didn't start with Test (not inheriting from unittest). I couldn't find  
that bit in the documentation that mentioned that - I will try to  
write up a small py.test in 1 minute document that you could use.

>> I suggest that you add this crucial information in a more clear way
>> (it is there, but not very discoverable) or even better, integrate  
>> the
>> py_unittest collection into py.test - this way people can try out
>> their old tests with py.test, rather than having to convert  
>> everything.
>
> good point.  So far i was hesitant with promoting it
> because i wanted to spend a bit more time into docs and
> an infrastructure that helps with checking that things
> are consistent.  It apparently gets about time now :)

I suggest that version 1 should have this bit in, it will help a lot  
of people to give it a casual go :)

Regards,
Orestis

From nshepperd at gmail.com  Mon Sep 22 03:53:48 2008
From: nshepperd at gmail.com (Neil Shepperd)
Date: Mon, 22 Sep 2008 11:53:48 +1000
Subject: [py-dev] py.test --looponfailing (SVN r58313) AssertionError
Message-ID: <1222048428.26602.15.camel@neil>

Hi all,

Py.test dies with an assertion error when I change the name
of a failing test, or move the file or directory it's in. It
looks like it's just trying to get the result of the test without
checking whether it exists first.

This is with the HEAD revision.

Neil

----------------
Example:

[test_blah.py]
def test_blah():
    assert False

$ py.test --looponfailing

[edit test_blah.py]
-def test_blah():
+def test_x():

Traceback (most recent call last):
...
AssertionError: Collector <Module 'test_blah.py'> does not have name
'test_blah' existing names are: ['test_blah.py']


From holger at merlinux.eu  Mon Sep 22 15:16:43 2008
From: holger at merlinux.eu (holger krekel)
Date: Mon, 22 Sep 2008 15:16:43 +0200
Subject: [py-dev] py.test --looponfailing (SVN r58313) AssertionError
In-Reply-To: <1222048428.26602.15.camel@neil>
References: <1222048428.26602.15.camel@neil>
Message-ID: <20080922131643.GG19528@trillke.net>

Hi Neil, 

thanks for your good report!   I just committed a fix in 58319
let me know if it solves the issue. 

holger

On Mon, Sep 22, 2008 at 11:53 +1000, Neil Shepperd wrote:
> Hi all,
> 
> Py.test dies with an assertion error when I change the name
> of a failing test, or move the file or directory it's in. It
> looks like it's just trying to get the result of the test without
> checking whether it exists first.
> 
> This is with the HEAD revision.
> 
> Neil
> 
> ----------------
> Example:
> 
> [test_blah.py]
> def test_blah():
>     assert False
> 
> $ py.test --looponfailing
> 
> [edit test_blah.py]
> -def test_blah():
> +def test_x():
> 
> Traceback (most recent call last):
> ...
> AssertionError: Collector <Module 'test_blah.py'> does not have name
> 'test_blah' existing names are: ['test_blah.py']
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

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