From holger at merlinux.eu  Fri Jan  1 19:37:36 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 1 Jan 2010 19:37:36 +0100
Subject: [py-dev] funcarg in a class
In-Reply-To: <e1ac8ece0912310925h5cad4807m7095d00c3da0f9fa@mail.gmail.com>
References: <e1ac8ece0912310925h5cad4807m7095d00c3da0f9fa@mail.gmail.com>
Message-ID: <20100101183736.GU3516@trillke.net>

On Thu, Dec 31, 2009 at 17:25 +0000, Joan Miller wrote:
> Is possible to run a funcarg inner of a class? The nex code doesnt works.
> 
> --------------------------
> class TestFoo(object):
> 
>     def pytest_funcarg__myfuncarg(self, request):
>         return 13
> 
> 
>     def test_function(self, append):
>         assert self.myfuncarg == 13

you need to pass in "myfuncarg" instead of "append". 
That should work fine. 

cheers,
holger

From holger at merlinux.eu  Fri Jan  1 19:46:25 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 1 Jan 2010 19:46:25 +0100
Subject: [py-dev] funcarg in a class
In-Reply-To: <20100101183736.GU3516@trillke.net>
References: <e1ac8ece0912310925h5cad4807m7095d00c3da0f9fa@mail.gmail.com>
	<20100101183736.GU3516@trillke.net>
Message-ID: <20100101184625.GV3516@trillke.net>

On Fri, Jan 01, 2010 at 19:37 +0100, holger krekel wrote:
> On Thu, Dec 31, 2009 at 17:25 +0000, Joan Miller wrote:
> > Is possible to run a funcarg inner of a class? The nex code doesnt works.
> > 
> > --------------------------
> > class TestFoo(object):
> > 
> >     def pytest_funcarg__myfuncarg(self, request):
> >         return 13
> > 
> > 
> >     def test_function(self, append):
> >         assert self.myfuncarg == 13
> 
> you need to pass in "myfuncarg" instead of "append". 
> That should work fine. 

to be precise:

    def test_function(self, myfuncarg):
        assert myfuncarg == 13

should work.  or do you mean something else? 

cheers and happy new year! 
holger

From peloko45 at gmail.com  Fri Jan  1 23:58:11 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Fri, 1 Jan 2010 22:58:11 +0000
Subject: [py-dev] funcarg in a class
In-Reply-To: <20100101184625.GV3516@trillke.net>
References: <e1ac8ece0912310925h5cad4807m7095d00c3da0f9fa@mail.gmail.com>
	<20100101183736.GU3516@trillke.net>
	<20100101184625.GV3516@trillke.net>
Message-ID: <e1ac8ece1001011458h2b803c0cod9abdf205aee2d5e@mail.gmail.com>

Thanks! I could solve it after of having written to the mailing list.
Sometimes the things go out when you make something in the background.

Happy new year!

2010/1/1 holger krekel <holger at merlinux.eu>:
> On Fri, Jan 01, 2010 at 19:37 +0100, holger krekel wrote:
>> On Thu, Dec 31, 2009 at 17:25 +0000, Joan Miller wrote:
>> > Is possible to run a funcarg inner of a class? The nex code doesnt works.
>> >
>> > --------------------------
>> > class TestFoo(object):
>> >
>> > ? ? def pytest_funcarg__myfuncarg(self, request):
>> > ? ? ? ? return 13
>> >
>> >
>> > ? ? def test_function(self, append):
>> > ? ? ? ? assert self.myfuncarg == 13
>>
>> you need to pass in "myfuncarg" instead of "append".
>> That should work fine.
>
> to be precise:
>
> ? ?def test_function(self, myfuncarg):
> ? ? ? ?assert myfuncarg == 13
>
> should work. ?or do you mean something else?
>
> cheers and happy new year!
> holger
>

From holger at merlinux.eu  Sat Jan  2 17:42:54 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 2 Jan 2010 17:42:54 +0100
Subject: [py-dev] happy new year / testing resources
Message-ID: <20100102164254.GX3516@trillke.net>

Hi all, 

i hope you all had a good entry into 2010, happy new decade! :)

The last days i have been on and off working towards a 1.2 
release.  One of the new bits is direct xml/junit reporting.
In fact i have been playing with Hudson as a build integration 
server, am quite happy so far. In case you'd like to see 
here is some preliminiary access: http://mer1.ath.cx:8080 
will put it somewhere more public soon. 

One thing i'd like to have is some more Boxes to play with :)
So if you can provide some virtual environment even only during
certain times, please contact me.  Personally, I use VirtualBox 
(after having used lots of XEN and a bit of KVM) and am quite 
happy with it, very easy to get going.  Connecting to the hudson 
master can be done in a "PULL" fashion and due to the virtualization 
is rather safe.  

cheers,
holger

From pedronis at openend.se  Sun Jan  3 15:14:11 2010
From: pedronis at openend.se (Samuele Pedroni)
Date: Sun, 03 Jan 2010 15:14:11 +0100
Subject: [py-dev] ANN: oejskit 0.8.7 JavaScript in-browser testing with
 py.test plugin and unittest.py glue
Message-ID: <4B40A633.9040000@openend.se>

Hi, I just pushed a new release of OE jskit 0.8.7 to PyPI. Main points
of interest:

- user-defined naming of browsers for the remote browser script so that
it is easier to run a test suite for example against machines running
ie7 and ie8 both, see "Remote browsers" in the doc for more details.

- the glue code to run JavaScript tests with unittest.py is now documented

- compatibility with py.test 1.1.1 cleanups, the plugin is now exposed
to py.test through a setuptools entry point

About OE jskit:

jskit contains infrastructure and in particular a py.test plugin to
enable running unit tests for JavaScript code inside browsers.
It contains also glue code to run JavaScript tests from unittest.py
based test suites.

The approach also enables to write integration tests such that the
JavaScript code is tested against server-side Python code mocked as
necessary. Any server-side framework that can already be exposed through
WSGI can play.

The plugin requires py.test 1.1.1 and should also work with current trunk.

More information and downloading at:

http://pypi.python.org/pypi/oejskit

including a changelog, documentation and the talk I gave at Europython 2009.

jskit was initially developed by Open End AB and is released under the
MIT license.

In various incarnations it has been in use and useful at Open End for
more than two years, we are quite happy to share it.

Samuele Pedroni for Open End
















From peloko45 at gmail.com  Sat Jan  9 11:15:02 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Sat, 9 Jan 2010 10:15:02 +0000
Subject: [py-dev] Ignore some tests
Message-ID: <e1ac8ece1001090215n70d1ef30sb8ea5de168eb7bf7@mail.gmail.com>

How to ignore any tests? Now I'm commenting the tests that I wann't
that they been runned but this is not optimal.

From Adam.Schmalhofer at gmx.de  Sat Jan  9 11:33:39 2010
From: Adam.Schmalhofer at gmx.de (Adam)
Date: Sat, 9 Jan 2010 11:33:39 +0100
Subject: [py-dev] Ignore some tests
In-Reply-To: <e1ac8ece1001090215n70d1ef30sb8ea5de168eb7bf7@mail.gmail.com>
References: <e1ac8ece1001090215n70d1ef30sb8ea5de168eb7bf7@mail.gmail.com>
Message-ID: <20100109113339.4d8c9ddf@deepthought>

Joan Miller wrote:

> Now I'm commenting the tests that I wann't
> that they been runned but this is not optimal.

http://codespeak.net/py/dist/test/features.html#advanced-test-selection-and-running-modes

http://codespeak.net/py/dist/test/plugin/skipping.html

--Adam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20100109/e5ba4e33/attachment.pgp 

From Ronny.Pfannschmidt at gmx.de  Sat Jan 16 11:08:34 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sat, 16 Jan 2010 11:08:34 +0100
Subject: [py-dev] output collect failure i dont quiete get
Message-ID: <1263636514.7949.150.camel@localhost>

hi,

while investigating some failing tests for pidas vim integration i
discovered that somehow some output is missing

for comparisation

/////////////////////////////////////////////////////////////////////////////////////////////
$ py.test
pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
inserting into sys.path: /home/ronny/Projects/py
============================= test session starts
==============================
python: platform linux2 -- Python 2.6.4 -- pytest-1.2.0a1
test object 1:
pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor

pida/editors/vim/test_pidavim.py E

==================================== ERRORS
====================================
_____________ ERROR at setup of TestVim.test_append_text_at_cursor
_____________

self = <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>
method = <bound method TestVim.test_append_text_at_cursor of
<pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>>

    def setup_method(self, method=None):
        self.vim_process = _start_vim()
        time.sleep(1)
>       self.vim = get_vim('pidatest')

pida/editors/vim/test_pidavim.py:51: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ 

uid = 'pidatest'

    def get_vim(uid):
        session = dbus.SessionBus()
        for _try in range(10):
            try:
                log.debug('trying vim connect #%s', _try)
                return session.get_object(get_bus_name(uid), '/vim')
            except dbus.DBusException:
                log.debug('vim connect failed, retrying')
                time.sleep(0.1)
>       raise RuntimeError('Vim Connect Failed')
E       RuntimeError: Vim Connect Failed

pida/editors/vim/client.py:39: RuntimeError
------------------------------- Captured stdout
--------------------------------
Vim: Caught deadly signal SEGV

Vim: Finished.

/////////////////////////////////////////////////////////////////////////////////////////////
$ nosetests
pida.editors.vim.test_pidavim:TestVim.test_append_text_at_cursor
beginning vim startup
modules loaded
get uuid
make service
made service
setup gui
done setup gui
Vim: Caught deadly signal SEGV
Vim: Finished.
E
======================================================================
ERROR: pida.editors.vim.test_pidavim.TestVim.test_append_text_at_cursor
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.6/site-packages/nose/case.py", line 364, in
setUp
    try_run(self.inst, ('setup', 'setUp'))
  File "/usr/lib64/python2.6/site-packages/nose/util.py", line 487, in
try_run
    return func()
  File
"/home/ronny/Projects/pida/main/pida/editors/vim/test_pidavim.py", line
51, in setup_method
    self.vim = get_vim('pidatest')
  File "/home/ronny/Projects/pida/main/pida/editors/vim/client.py", line
39, in get_vim
    raise RuntimeError('Vim Connect Failed')
RuntimeError: Vim Connect Failed

----------------------------------------------------------------------
Ran 1 test in 2.051s

FAILED (errors=1)
/////////////////////////////////////////////////////////////////////////////////////////////

i suppose this relates to py.test's output captureing and vim's
behaviour wrt not having a pty

any idea how to work around that without just disableing the captureing?

Regards Ronny


From holger at merlinux.eu  Sat Jan 16 11:56:17 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 16 Jan 2010 11:56:17 +0100
Subject: [py-dev] output collect failure i dont quiete get
In-Reply-To: <1263636514.7949.150.camel@localhost>
References: <1263636514.7949.150.camel@localhost>
Message-ID: <20100116105617.GE3516@trillke.net>

Moin Ronny,

sorry, i can not reproduce the issue - probably i am missing something. 
Could you come up with a minimal example and tell how you 
invoke nosetests and py.test?  Maybe also use some paste service 
so that they are more nicely readable.  And are you using the released
or trunk-nosetests? 

cheers,
holger

On Sat, Jan 16, 2010 at 11:08 +0100, Ronny Pfannschmidt wrote:
> hi,
> 
> while investigating some failing tests for pidas vim integration i
> discovered that somehow some output is missing
> 
> for comparisation
> 
> /////////////////////////////////////////////////////////////////////////////////////////////
> $ py.test
> pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> inserting into sys.path: /home/ronny/Projects/py
> ============================= test session starts
> ==============================
> python: platform linux2 -- Python 2.6.4 -- pytest-1.2.0a1
> test object 1:
> pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> 
> pida/editors/vim/test_pidavim.py E
> 
> ==================================== ERRORS
> ====================================
> _____________ ERROR at setup of TestVim.test_append_text_at_cursor
> _____________
> 
> self = <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>
> method = <bound method TestVim.test_append_text_at_cursor of
> <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>>
> 
>     def setup_method(self, method=None):
>         self.vim_process = _start_vim()
>         time.sleep(1)
> >       self.vim = get_vim('pidatest')
> 
> pida/editors/vim/test_pidavim.py:51: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ 
> 
> uid = 'pidatest'
> 
>     def get_vim(uid):
>         session = dbus.SessionBus()
>         for _try in range(10):
>             try:
>                 log.debug('trying vim connect #%s', _try)
>                 return session.get_object(get_bus_name(uid), '/vim')
>             except dbus.DBusException:
>                 log.debug('vim connect failed, retrying')
>                 time.sleep(0.1)
> >       raise RuntimeError('Vim Connect Failed')
> E       RuntimeError: Vim Connect Failed
> 
> pida/editors/vim/client.py:39: RuntimeError
> ------------------------------- Captured stdout
> --------------------------------
> Vim: Caught deadly signal SEGV
> 
> Vim: Finished.
> 
> /////////////////////////////////////////////////////////////////////////////////////////////
> $ nosetests
> pida.editors.vim.test_pidavim:TestVim.test_append_text_at_cursor
> beginning vim startup
> modules loaded
> get uuid
> make service
> made service
> setup gui
> done setup gui
> Vim: Caught deadly signal SEGV
> Vim: Finished.
> E
> ======================================================================
> ERROR: pida.editors.vim.test_pidavim.TestVim.test_append_text_at_cursor
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib64/python2.6/site-packages/nose/case.py", line 364, in
> setUp
>     try_run(self.inst, ('setup', 'setUp'))
>   File "/usr/lib64/python2.6/site-packages/nose/util.py", line 487, in
> try_run
>     return func()
>   File
> "/home/ronny/Projects/pida/main/pida/editors/vim/test_pidavim.py", line
> 51, in setup_method
>     self.vim = get_vim('pidatest')
>   File "/home/ronny/Projects/pida/main/pida/editors/vim/client.py", line
> 39, in get_vim
>     raise RuntimeError('Vim Connect Failed')
> RuntimeError: Vim Connect Failed
> 
> ----------------------------------------------------------------------
> Ran 1 test in 2.051s
> 
> FAILED (errors=1)
> /////////////////////////////////////////////////////////////////////////////////////////////
> 
> i suppose this relates to py.test's output captureing and vim's
> behaviour wrt not having a pty
> 
> any idea how to work around that without just disableing the captureing?
> 
> Regards Ronnyk
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 

From Ronny.Pfannschmidt at gmx.de  Sat Jan 16 11:59:04 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sat, 16 Jan 2010 11:59:04 +0100
Subject: [py-dev] output collect failure i dont quiete get
In-Reply-To: <20100116105617.GE3516@trillke.net>
References: <1263636514.7949.150.camel@localhost>
	<20100116105617.GE3516@trillke.net>
Message-ID: <1263639544.7949.153.camel@localhost>

On Sat, 2010-01-16 at 11:56 +0100, holger krekel wrote:
> Moin Ronny,
> 
> sorry, i can not reproduce the issue - probably i am missing something. 
> Could you come up with a minimal example and tell how you 
> invoke nosetests and py.test?  Maybe also use some paste service 
> so that they are more nicely readable.  And are you using the released
> or trunk-nosetests? 
the issue is vim changing output behaviour based on having a pty on
stdin
> 
> cheers,
> holger
> 
> On Sat, Jan 16, 2010 at 11:08 +0100, Ronny Pfannschmidt wrote:
> > hi,
> > 
> > while investigating some failing tests for pidas vim integration i
> > discovered that somehow some output is missing
> > 
> > for comparisation
> > 
> > /////////////////////////////////////////////////////////////////////////////////////////////
> > $ py.test
> > pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> > inserting into sys.path: /home/ronny/Projects/py
> > ============================= test session starts
> > ==============================
> > python: platform linux2 -- Python 2.6.4 -- pytest-1.2.0a1
> > test object 1:
> > pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> > 
> > pida/editors/vim/test_pidavim.py E
> > 
> > ==================================== ERRORS
> > ====================================
> > _____________ ERROR at setup of TestVim.test_append_text_at_cursor
> > _____________
> > 
> > self = <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>
> > method = <bound method TestVim.test_append_text_at_cursor of
> > <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>>
> > 
> >     def setup_method(self, method=None):
> >         self.vim_process = _start_vim()
> >         time.sleep(1)
> > >       self.vim = get_vim('pidatest')
> > 
> > pida/editors/vim/test_pidavim.py:51: 
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> > _ _ _ _ 
> > 
> > uid = 'pidatest'
> > 
> >     def get_vim(uid):
> >         session = dbus.SessionBus()
> >         for _try in range(10):
> >             try:
> >                 log.debug('trying vim connect #%s', _try)
> >                 return session.get_object(get_bus_name(uid), '/vim')
> >             except dbus.DBusException:
> >                 log.debug('vim connect failed, retrying')
> >                 time.sleep(0.1)
> > >       raise RuntimeError('Vim Connect Failed')
> > E       RuntimeError: Vim Connect Failed
> > 
> > pida/editors/vim/client.py:39: RuntimeError
> > ------------------------------- Captured stdout
> > --------------------------------
> > Vim: Caught deadly signal SEGV
> > 
> > Vim: Finished.
> > 
> > /////////////////////////////////////////////////////////////////////////////////////////////
> > $ nosetests
> > pida.editors.vim.test_pidavim:TestVim.test_append_text_at_cursor
> > beginning vim startup
> > modules loaded
> > get uuid
> > make service
> > made service
> > setup gui
> > done setup gui
> > Vim: Caught deadly signal SEGV
> > Vim: Finished.
> > E
> > ======================================================================
> > ERROR: pida.editors.vim.test_pidavim.TestVim.test_append_text_at_cursor
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> >   File "/usr/lib64/python2.6/site-packages/nose/case.py", line 364, in
> > setUp
> >     try_run(self.inst, ('setup', 'setUp'))
> >   File "/usr/lib64/python2.6/site-packages/nose/util.py", line 487, in
> > try_run
> >     return func()
> >   File
> > "/home/ronny/Projects/pida/main/pida/editors/vim/test_pidavim.py", line
> > 51, in setup_method
> >     self.vim = get_vim('pidatest')
> >   File "/home/ronny/Projects/pida/main/pida/editors/vim/client.py", line
> > 39, in get_vim
> >     raise RuntimeError('Vim Connect Failed')
> > RuntimeError: Vim Connect Failed
> > 
> > ----------------------------------------------------------------------
> > Ran 1 test in 2.051s
> > 
> > FAILED (errors=1)
> > /////////////////////////////////////////////////////////////////////////////////////////////
> > 
> > i suppose this relates to py.test's output captureing and vim's
> > behaviour wrt not having a pty
> > 
> > any idea how to work around that without just disableing the captureing?
> > 
> > Regards Ronnyk
> > 
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> > 
> 


From holger at merlinux.eu  Sat Jan 16 12:16:37 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 16 Jan 2010 12:16:37 +0100
Subject: [py-dev] output collect failure i dont quiete get
In-Reply-To: <1263639544.7949.153.camel@localhost>
References: <1263636514.7949.150.camel@localhost>
	<20100116105617.GE3516@trillke.net>
	<1263639544.7949.153.camel@localhost>
Message-ID: <20100116111637.GF3516@trillke.net>

On Sat, Jan 16, 2010 at 11:59 +0100, Ronny Pfannschmidt wrote:
> On Sat, 2010-01-16 at 11:56 +0100, holger krekel wrote:
> > Moin Ronny,
> > 
> > sorry, i can not reproduce the issue - probably i am missing something. 
> > Could you come up with a minimal example and tell how you 
> > invoke nosetests and py.test?  Maybe also use some paste service 
> > so that they are more nicely readable.  And are you using the released
> > or trunk-nosetests? 
> the issue is vim changing output behaviour based on having a pty on
> stdin

So if i understand it correctly: py.test indeed by default
opens /dev/null and puts that file to sys.stdin (also on fd-level)
so that tests can not hang waiting for input.  I guess
we could introduce an option to leave stdin alone. Alternatively
you could maybe use os.openpty and dup that to filedescriptor 0
before invoking vim-machinery?

cheers,
holger

P.S.: I spent 20+ minutes on this previously - i'd appreciate if you tried
to be a bit more precise than "somehow some output is missing" and a bunch of
tracebacks.  

> > 
> > cheers,
> > holger
> > 
> > On Sat, Jan 16, 2010 at 11:08 +0100, Ronny Pfannschmidt wrote:
> > > hi,
> > > 
> > > while investigating some failing tests for pidas vim integration i
> > > discovered that somehow some output is missing
> > > 
> > > for comparisation
> > > 
> > > /////////////////////////////////////////////////////////////////////////////////////////////
> > > $ py.test
> > > pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> > > inserting into sys.path: /home/ronny/Projects/py
> > > ============================= test session starts
> > > ==============================
> > > python: platform linux2 -- Python 2.6.4 -- pytest-1.2.0a1
> > > test object 1:
> > > pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> > > 
> > > pida/editors/vim/test_pidavim.py E
> > > 
> > > ==================================== ERRORS
> > > ====================================
> > > _____________ ERROR at setup of TestVim.test_append_text_at_cursor
> > > _____________
> > > 
> > > self = <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>
> > > method = <bound method TestVim.test_append_text_at_cursor of
> > > <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>>
> > > 
> > >     def setup_method(self, method=None):
> > >         self.vim_process = _start_vim()
> > >         time.sleep(1)
> > > >       self.vim = get_vim('pidatest')
> > > 
> > > pida/editors/vim/test_pidavim.py:51: 
> > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> > > _ _ _ _ 
> > > 
> > > uid = 'pidatest'
> > > 
> > >     def get_vim(uid):
> > >         session = dbus.SessionBus()
> > >         for _try in range(10):
> > >             try:
> > >                 log.debug('trying vim connect #%s', _try)
> > >                 return session.get_object(get_bus_name(uid), '/vim')
> > >             except dbus.DBusException:
> > >                 log.debug('vim connect failed, retrying')
> > >                 time.sleep(0.1)
> > > >       raise RuntimeError('Vim Connect Failed')
> > > E       RuntimeError: Vim Connect Failed
> > > 
> > > pida/editors/vim/client.py:39: RuntimeError
> > > ------------------------------- Captured stdout
> > > --------------------------------
> > > Vim: Caught deadly signal SEGV
> > > 
> > > Vim: Finished.
> > > 
> > > /////////////////////////////////////////////////////////////////////////////////////////////
> > > $ nosetests
> > > pida.editors.vim.test_pidavim:TestVim.test_append_text_at_cursor
> > > beginning vim startup
> > > modules loaded
> > > get uuid
> > > make service
> > > made service
> > > setup gui
> > > done setup gui
> > > Vim: Caught deadly signal SEGV
> > > Vim: Finished.
> > > E
> > > ======================================================================
> > > ERROR: pida.editors.vim.test_pidavim.TestVim.test_append_text_at_cursor
> > > ----------------------------------------------------------------------
> > > Traceback (most recent call last):
> > >   File "/usr/lib64/python2.6/site-packages/nose/case.py", line 364, in
> > > setUp
> > >     try_run(self.inst, ('setup', 'setUp'))
> > >   File "/usr/lib64/python2.6/site-packages/nose/util.py", line 487, in
> > > try_run
> > >     return func()
> > >   File
> > > "/home/ronny/Projects/pida/main/pida/editors/vim/test_pidavim.py", line
> > > 51, in setup_method
> > >     self.vim = get_vim('pidatest')
> > >   File "/home/ronny/Projects/pida/main/pida/editors/vim/client.py", line
> > > 39, in get_vim
> > >     raise RuntimeError('Vim Connect Failed')
> > > RuntimeError: Vim Connect Failed
> > > 
> > > ----------------------------------------------------------------------
> > > Ran 1 test in 2.051s
> > > 
> > > FAILED (errors=1)
> > > /////////////////////////////////////////////////////////////////////////////////////////////
> > > 
> > > i suppose this relates to py.test's output captureing and vim's
> > > behaviour wrt not having a pty
> > > 
> > > any idea how to work around that without just disableing the captureing?
> > > 
> > > Regards Ronnyk
> > > 
> > > _______________________________________________
> > > py-dev mailing list
> > > py-dev at codespeak.net
> > > http://codespeak.net/mailman/listinfo/py-dev
> > > 
> > 
> 

-- 

From Ronny.Pfannschmidt at gmx.de  Sun Jan 17 18:53:47 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sun, 17 Jan 2010 18:53:47 +0100
Subject: [py-dev] how to configure additional traceback cut-out
Message-ID: <1263750827.29378.3.camel@localhost>

hi,

while debugging vim-dbus use, 
i'd like to remove all those nasty line-nosie alike traceback iems  from
the python dbus libs as they don't really help the traceback.

Is there any way to do that right now or does it need invention.

-- Ronny


From holger at merlinux.eu  Sun Jan 17 20:25:18 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 17 Jan 2010 20:25:18 +0100
Subject: [py-dev] how to configure additional traceback cut-out
In-Reply-To: <1263750827.29378.3.camel@localhost>
References: <1263750827.29378.3.camel@localhost>
Message-ID: <20100117192517.GD30119@trillke.net>

Hi Ronny, 

On Sun, Jan 17, 2010 at 18:53 +0100, Ronny Pfannschmidt wrote:
> hi,
> 
> while debugging vim-dbus use, 
> i'd like to remove all those nasty line-nosie alike traceback iems  from
> the python dbus libs as they don't really help the traceback.
> 
> Is there any way to do that right now or does it need invention.

No way yet.  The "__tracebackhide__ = True" setting only works for code
you control, obviously.  

However, the internal ExceptionInfo() object has support for processing
tracebacks so i guess we could add a hook that you can use like this:

    # ./conftest.py
    def pytest_filter_traceback(excinfo):
        dbuspath = py.path.local(dbus.__file__).dirpath()
        excinfo.traceback = excinfo.traceback.filter(
            lambda entry: not entry.path.relto(dbuspath))

This hook should not be called when "--tb=full" is specified, i guess.

makes sense to you? 

cheers,
holger

From Ronny.Pfannschmidt at gmx.de  Sun Jan 17 20:49:25 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sun, 17 Jan 2010 20:49:25 +0100
Subject: [py-dev] how to configure additional traceback cut-out
In-Reply-To: <20100117192517.GD30119@trillke.net>
References: <1263750827.29378.3.camel@localhost>
	<20100117192517.GD30119@trillke.net>
Message-ID: <1263757765.29378.26.camel@localhost>

On Sun, 2010-01-17 at 20:25 +0100, holger krekel wrote:
> Hi Ronny, 
> 
> On Sun, Jan 17, 2010 at 18:53 +0100, Ronny Pfannschmidt wrote:
> > hi,
> > 
> > while debugging vim-dbus use, 
> > i'd like to remove all those nasty line-nosie alike traceback iems  from
> > the python dbus libs as they don't really help the traceback.
> > 
> > Is there any way to do that right now or does it need invention.
> 
> No way yet.  The "__tracebackhide__ = True" setting only works for code
> you control, obviously.  
> 
> However, the internal ExceptionInfo() object has support for processing
> tracebacks so i guess we could add a hook that you can use like this:
> 
>     # ./conftest.py
>     def pytest_filter_traceback(excinfo):
>         dbuspath = py.path.local(dbus.__file__).dirpath()
>         excinfo.traceback = excinfo.traceback.filter(
>             lambda entry: not entry.path.relto(dbuspath))
> 
> This hook should not be called when "--tb=full" is specified, i guess.
> 
> makes sense to you? 
> 
that looks very sensible, i'll take a look at where to put that, 
seems like traceback pruning is somewhere in collect

since its about filtering tracebacks,
how about having it take a traceback and return one
so one could do something like:

def pytest_filter_traceback(traceback):
   dbuspath = py.path.local(dbus.__file__).dirpath()
   return traceback.filter(lambda entry: not entry.path.relto(dbuspath))


-- Ronny


From holger at merlinux.eu  Sun Jan 17 21:16:03 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 17 Jan 2010 21:16:03 +0100
Subject: [py-dev] how to configure additional traceback cut-out
In-Reply-To: <1263757765.29378.26.camel@localhost>
References: <1263750827.29378.3.camel@localhost>
	<20100117192517.GD30119@trillke.net>
	<1263757765.29378.26.camel@localhost>
Message-ID: <20100117201603.GE30119@trillke.net>

On Sun, Jan 17, 2010 at 20:49 +0100, Ronny Pfannschmidt wrote:
> On Sun, 2010-01-17 at 20:25 +0100, holger krekel wrote:
> > Hi Ronny, 
> > 
> > On Sun, Jan 17, 2010 at 18:53 +0100, Ronny Pfannschmidt wrote:
> > > hi,
> > > 
> > > while debugging vim-dbus use, 
> > > i'd like to remove all those nasty line-nosie alike traceback iems  from
> > > the python dbus libs as they don't really help the traceback.
> > > 
> > > Is there any way to do that right now or does it need invention.
> > 
> > No way yet.  The "__tracebackhide__ = True" setting only works for code
> > you control, obviously.  
> > 
> > However, the internal ExceptionInfo() object has support for processing
> > tracebacks so i guess we could add a hook that you can use like this:
> > 
> >     # ./conftest.py
> >     def pytest_filter_traceback(excinfo):
> >         dbuspath = py.path.local(dbus.__file__).dirpath()
> >         excinfo.traceback = excinfo.traceback.filter(
> >             lambda entry: not entry.path.relto(dbuspath))
> > 
> > This hook should not be called when "--tb=full" is specified, i guess.
> > 
> > makes sense to you? 
> > 
> that looks very sensible, i'll take a look at where to put that, 
> seems like traceback pruning is somewhere in collect
> 
> since its about filtering tracebacks,
> how about having it take a traceback and return one
> so one could do something like:
> 
> def pytest_filter_traceback(traceback):
>    dbuspath = py.path.local(dbus.__file__).dirpath()
>    return traceback.filter(lambda entry: not entry.path.relto(dbuspath))

This would inhibit having multiple hooks involved. There is no
hook-call mode which allows to "chain", so far it wasn't 
strictly needed. 

Adding pytest_filter_traceback to py/_plugin/hookspec.py 
and shifting the traceback.filter() call in pycollect.py::_prunetraceback 
to a default hook in py/_plugin/pytest_default.py and adding
a self.ihook.pytest_filter_traceback(excinfo=excinfo) instead should 
be enough to allow a custom conftest.py hook.  And of course a test in 
testing/test_pycollect.py::TestConftestCustomization

cheers,
holger

From Ronny.Pfannschmidt at gmx.de  Sun Jan 17 22:27:54 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sun, 17 Jan 2010 22:27:54 +0100
Subject: [py-dev] confusion on traceback.cut
Message-ID: <1263763674.29378.36.camel@localhost>

Hi,
just played around with traceback cut/filter
but i don't understand whats happening here:

        >>> import py
        >>> py._pydir
        local('/home/ronny/Projects/py/py')
        >>> e = py.test.raises(ValueError, "int('a')")
        >>> tb = e.traceback
        >>> tb.cut(excludepath=py._pydir)
        [<TracebackEntry /home/ronny/Projects/py/py/_test/outcome.py:89>, <TracebackEntry /home/ronny/Projects/py/py/_builtin.py:179>, <TracebackEntry <string>:5>, <TracebackEntry <codegen /home/ronny/Projects/py/py/_test/outcome.py:88>:1>]


i expected it to remove the first few items

on the other hand
        >>> tb.filter(lambda x:not
        py.path.local(x.path).relto(py._pydir))
        [<TracebackEntry <string>:5>, <TracebackEntry
        <codegen /home/ronny/Projects/py/py/_test/outcome.py:88>:1>]
        
seems to do exactly that and i expected it to filter the last entry, too

can we please clarify what each of those really.

ps:
        ~/Projects/py $ hg id
        201d526c373c (trunk) tip

Regards Ronny



From holger at merlinux.eu  Mon Jan 18 03:06:54 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Jan 2010 03:06:54 +0100
Subject: [py-dev] confusion on traceback.cut
In-Reply-To: <1263763674.29378.36.camel@localhost>
References: <1263763674.29378.36.camel@localhost>
Message-ID: <20100118020654.GF30119@trillke.net>

Hi Ronny,

On Sun, Jan 17, 2010 at 22:27 +0100, Ronny Pfannschmidt wrote:
> Hi,
> just played around with traceback cut/filter
> but i don't understand whats happening here:
> 
>         >>> import py
>         >>> py._pydir
>         local('/home/ronny/Projects/py/py')
>         >>> e = py.test.raises(ValueError, "int('a')")
>         >>> tb = e.traceback
>         >>> tb.cut(excludepath=py._pydir)
>         [<TracebackEntry /home/ronny/Projects/py/py/_test/outcome.py:89>, <TracebackEntry /home/ronny/Projects/py/py/_builtin.py:179>, <TracebackEntry <string>:5>, <TracebackEntry <codegen /home/ronny/Projects/py/py/_test/outcome.py:88>:1>]

A slightly special case because other than the pydir only
synthetic code is involved (generated source).  If you have 
at least one "real" entry not relative to pydir it should work. 
Anyway, i changed this in rev1610 - let's see if it causes 
any problems (in py.test reporting).

> i expected it to remove the first few items
> 
> on the other hand
>         >>> tb.filter(lambda x:not
>         py.path.local(x.path).relto(py._pydir))
>         [<TracebackEntry <string>:5>, <TracebackEntry
>         <codegen /home/ronny/Projects/py/py/_test/outcome.py:88>:1>]
>         
> seems to do exactly that and i expected it to filter the last entry, too

The last entry is generated source, what you see if where it got generated.
By passing in a filter function you override the default filter
lambda x: not x.ishidden().  You can "AND" that in your lambda. 

> can we please clarify what each of those really.

hope it is now.

holger

From Ronny.Pfannschmidt at gmx.de  Mon Jan 18 12:00:48 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Mon, 18 Jan 2010 12:00:48 +0100
Subject: [py-dev] how should i handle errors in the traceback filter hooks
Message-ID: <1263812448.25759.8.camel@localhost>

hi,

i just finished the initial version of the traceback filter hook
while it was just as simple as holger said, i lack an idea on how to
handle errors in that hook.

btw, the current patch is http://paste.pocoo.org/show/166660/


so it spills out a nasty/huge internalerror if i make misstakes in my
own implementations of that hook within a conftest.

tests will be written once i figure the error handling

-- Ronny


From holger at merlinux.eu  Mon Jan 18 14:58:25 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Jan 2010 14:58:25 +0100
Subject: [py-dev] how should i handle errors in the traceback
	filter	hooks
In-Reply-To: <1263812448.25759.8.camel@localhost>
References: <1263812448.25759.8.camel@localhost>
Message-ID: <20100118135825.GK30119@trillke.net>

On Mon, Jan 18, 2010 at 12:00 +0100, Ronny Pfannschmidt wrote:
> hi,
> 
> i just finished the initial version of the traceback filter hook
> while it was just as simple as holger said, i lack an idea on how to
> handle errors in that hook.
> 
> btw, the current patch is http://paste.pocoo.org/show/166660/
> 
> 
> so it spills out a nasty/huge internalerror if i make misstakes in my
> own implementations of that hook within a conftest.

for now, i'd catch the exception and just use the un-abbreviated traceback. 

Maybe you can issue a hook.pytest_trace("filter_traceback", msg)
which one could see if "--debug" or "--traceconfig" is given. 

holger

> tests will be written once i figure the error handling
> 
> -- Ronny
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 

From fijall at gmail.com  Mon Jan 18 15:50:56 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 18 Jan 2010 15:50:56 +0100
Subject: [py-dev] Is codespeak issue tracker still active?
Message-ID: <693bc9ab1001180650p51b27400s6d0014ade90fc659@mail.gmail.com>

I mean this guy:

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

If it's not, probably a redirect would be good.
If it's working, then something went wrong with styles, at least for me.

Cheers,
fijal

From holger at merlinux.eu  Mon Jan 18 15:55:58 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Jan 2010 15:55:58 +0100
Subject: [py-dev] Is codespeak issue tracker still active?
In-Reply-To: <693bc9ab1001180650p51b27400s6d0014ade90fc659@mail.gmail.com>
References: <693bc9ab1001180650p51b27400s6d0014ade90fc659@mail.gmail.com>
Message-ID: <20100118145558.GL30119@trillke.net>

Hi Maciej,

On Mon, Jan 18, 2010 at 15:50 +0100, Maciej Fijalkowski wrote:
> I mean this guy:
> 
> https://codespeak.net/issue/py-dev/index
> 
> If it's not, probably a redirect would be good.
> If it's working, then something went wrong with styles, at least for me.

i disabled it now - as described in http://pylib.org/contact.html please use 

    http://bitbucket.org/hpk42/py-trunk/issues

or the mailing list here.

cheers,
holger

From Ronny.Pfannschmidt at gmx.de  Mon Jan 18 16:14:04 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Mon, 18 Jan 2010 16:14:04 +0100
Subject: [py-dev] another traceback cut weirdness
Message-ID: <1263827644.25759.13.camel@localhost>

i just noticed that traceback.cut will return a traceback
with all other filtering undone again
since it passes a raw traceback entry into the Traceback ctor.

is there any deeper reason for that or did it just work, cause cutting
always was first

if its not intentional i could add a .filter(lambda entry: entry in
self) to get it solved

-- Ronny


From holger at merlinux.eu  Mon Jan 18 16:24:36 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Jan 2010 16:24:36 +0100
Subject: [py-dev] another traceback cut weirdness
In-Reply-To: <1263827644.25759.13.camel@localhost>
References: <1263827644.25759.13.camel@localhost>
Message-ID: <20100118152436.GM30119@trillke.net>

Hi Ronny,

On Mon, Jan 18, 2010 at 16:14 +0100, Ronny Pfannschmidt wrote:
> i just noticed that traceback.cut will return a traceback
> with all other filtering undone again
> since it passes a raw traceback entry into the Traceback ctor.
> 
> is there any deeper reason for that or did it just work, cause cutting
> always was first

probably. The whole machinery was done for py.test which obviously
invokes it in a certain way. 

> if its not intentional i could add a .filter(lambda entry: entry in
> self) to get it solved

Sounds ok although i am not sure it's that easy.  Let's maybe 
continue any more discussion off-list as i guess not too many 
people here are interested in the details ... 

cheers,
holger

From holger at merlinux.eu  Mon Jan 18 17:34:33 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Jan 2010 17:34:33 +0100
Subject: [py-dev] py.test-1.2.0: junitxml, standalone test scripts,
	pluginization
Message-ID: <20100118163433.GO30119@trillke.net>

Hi all, 

i just released some bits related to testing: 

  py-1.2.0: py.test core which grew junitxml, standalone-script generation 
  pytest-xdist-1.0: separately installable dist-testing & looponfailing plugin
  pytest-figleaf-1.0: separately installable figleaf-coverage testing plugin

See below or at this URL for the announcement:

    http://pylib.org/announce/release-1.2.0.html

If you didn't experience much speed-up or had previously problems with 
distributed testing i recommend you try to install "pytest-xdist" now and see 
if it works better. For me it speeds up some tests runs by 500% on a 4 CPU
machine due to its better internal model and several fixes.  (It's five
times because several tests depend on IO and don't block CPU meanwhile).

Another tip: if you use "pip" (best with a virtualenv) you can do e.g.:

    pip install pytest-xdist 
    pip uninstall pytest-xdist 

to conveniently activate/deactivate plugins for py.test. easy_install 
works ok as well but has no uninstall, yet remains the only option 
for installing with Python3 at the moment, though.  You need to use
the 'distribute' project's easy_install for that. 

cheers & have fun,
holger


py.test/pylib 1.2.0: junitxml, standalone test scripts, pluginization
--------------------------------------------------------------------------------

py.test is an advanced automated testing tool working with
Python2, Python3 and Jython versions on all major operating
systems.  It has a simple plugin architecture and can run many 
existing common Python test suites without modification.  It offers 
some unique features not found in other testing tools.  
See http://pytest.org for more info.

py.test 1.2.0 brings many bug fixes and interesting new abilities:

* --junitxml=path will create an XML file for use with CI processing 
* --genscript=path creates a standalone py.test-equivalent test-script 
* --ignore=path prevents collection of anything below that path
* --confcutdir=path only lookup conftest.py test configs below that path
* a 'pytest_report_header' hook to add info to the terminal report header 
* a 'pytestconfig' function argument gives direct access to option values
* 'pytest_generate_tests' can now be put into a class as well 
* on CPython py.test additionally installs as "py.test-VERSION", on
  Jython as py.test-jython and on PyPy as py.test-pypy-XYZ

Apart from many bug fixes 1.2.0 also has better pluginization: 
Distributed testing and looponfailing testing now live in the
separately installable 'pytest-xdist' plugin.  The same is true for
'pytest-figleaf' for doing coverage reporting.  Those two plugins
can serve well now as blue prints for doing your own.  

thanks to all who helped and gave feedback,
have fun,

holger krekel, January 2010

Changes between 1.2.0 and 1.1.1
=====================================

- moved dist/looponfailing from py.test core into a new 
  separately released pytest-xdist plugin.

- new junitxml plugin: --junitxml=path will generate a junit style xml file
  which is processable e.g. by the Hudson CI system. 

- new option: --genscript=path will generate a standalone py.test script
  which will not need any libraries installed.  thanks to Ralf Schmitt. 

- new option: --ignore will prevent specified path from collection. 
  Can be specified multiple times. 

- new option: --confcutdir=dir will make py.test only consider conftest 
  files that are relative to the specified dir.  

- new funcarg: "pytestconfig" is the pytest config object for access
  to command line args and can now be easily used in a test. 

- install 'py.test' and `py.which` with a ``-$VERSION`` suffix to
  disambiguate between Python3, python2.X, Jython and PyPy installed versions. 

- new "pytestconfig" funcarg allows access to test config object

- new "pytest_report_header" hook can return additional lines 
  to be displayed at the header of a test run. 

- (experimental) allow "py.test path::name1::name2::..." for pointing
  to a test within a test collection directly.  This might eventually
  evolve as a full substitute to "-k" specifications. 

- streamlined plugin loading: order is now as documented in
  customize.html: setuptools, ENV, commandline, conftest. 
  also setuptools entry point names are turned to canonical namees ("pytest_*")

- automatically skip tests that need 'capfd' but have no os.dup 

- allow pytest_generate_tests to be defined in classes as well 

- deprecate usage of 'disabled' attribute in favour of pytestmark 
- deprecate definition of Directory, Module, Class and Function nodes
  in conftest.py files.  Use pytest collect hooks instead.

- collection/item node specific runtest/collect hooks are only called exactly
  on matching conftest.py files, i.e. ones which are exactly below
  the filesystem path of an item

- change: the first pytest_collect_directory hook to return something
  will now prevent further hooks to be called.

- change: figleaf plugin now requires --figleaf to run.  Also
  change its long command line options to be a bit shorter (see py.test -h).

- change: pytest doctest plugin is now enabled by default and has a
  new option --doctest-glob to set a pattern for file matches. 

- change: remove internal py._* helper vars, only keep py._pydir 

- robustify capturing to survive if custom pytest_runtest_setup 
  code failed and prevented the capturing setup code from running. 

- make py.test.* helpers provided by default plugins visible early -
  works transparently both for pydoc and for interactive sessions
  which will regularly see e.g. py.test.mark and py.test.importorskip. 

- simplify internal plugin manager machinery 
- simplify internal collection tree by introducing a RootCollector node

- fix assert reinterpreation that sees a call containing "keyword=..."

- fix issue66: invoke pytest_sessionstart and pytest_sessionfinish 
  hooks on slaves during dist-testing, report module/session teardown 
  hooks correctly.

- fix issue65: properly handle dist-testing if no 
  execnet/py lib installed remotely. 

- skip some install-tests if no execnet is available

- fix docs, fix internal bin/ script generation

-- 

From holger at merlinux.eu  Tue Jan 19 16:18:37 2010
From: holger at merlinux.eu (holger krekel)
Date: Tue, 19 Jan 2010 16:18:37 +0100
Subject: [py-dev] py.test-1.2.0: junitxml, standalone test scripts,
	pluginization
In-Reply-To: <20100118163433.GO30119@trillke.net>
References: <20100118163433.GO30119@trillke.net>
Message-ID: <20100119151837.GR30119@trillke.net>

On Mon, Jan 18, 2010 at 17:34 +0100, holger krekel wrote:
>   pytest-xdist-1.0: separately installable dist-testing & looponfailing plugin

pytest-xdist-1.1 is out, which avoids an indefinite hang if you have
few and quick hosts, and some fast-to-run tests.  The test-master would
in some cases end up wanting to avoid a busy-loop but in fact 
would stall because the test nodes were also waiting for new tasks. 
"pip install -U pytest-xdist" should fix this race condition now. 

holger

From wmark at hurrikane.de  Wed Jan 20 18:28:58 2010
From: wmark at hurrikane.de (W-Mark Kubacki)
Date: Wed, 20 Jan 2010 18:28:58 +0100
Subject: [py-dev] [patch] greenlet on ARM/linux
In-Reply-To: <9bca96021001200925m36e62d31s51f06e46e6b13535@mail.gmail.com>
References: <9bca96021001200925m36e62d31s51f06e46e6b13535@mail.gmail.com>
Message-ID: <9bca96021001200928u12b21c42rdcd507bf9100343@mail.gmail.com>

Hi,

last year Renaud Blanch has provided a patch for ARM/Apple. [1]
Based on his works I have ported 'greenlet' to ARM (EABI, non-thumb;
all tests passed). Please find my patch attached.

-- 
Gr??e, Mark
http://mark.ossdl.de/
(I am no subscriber to this list; regdarding this topic please CC me.)

[1] http://codespeak.net/pipermail/py-dev/2009q1/001066.html

From wmark at hurrikane.de  Wed Jan 20 18:32:54 2010
From: wmark at hurrikane.de (W-Mark Kubacki)
Date: Wed, 20 Jan 2010 18:32:54 +0100
Subject: [py-dev] [patch] greenlet on ARM/linux
In-Reply-To: <9bca96021001200928u12b21c42rdcd507bf9100343@mail.gmail.com>
References: <9bca96021001200925m36e62d31s51f06e46e6b13535@mail.gmail.com>
	<9bca96021001200928u12b21c42rdcd507bf9100343@mail.gmail.com>
Message-ID: <9bca96021001200932y633eb2b5tf468b898ba03255f@mail.gmail.com>

2010/1/20 W-Mark Kubacki <wmark at hurrikane.de>:
> Please find my patch attached.

Here comes the attachment. Sorry.

-- 
Gr??e, Mark
http://mark.ossdl.de/
(I am no subscriber to this list; regdarding this topic please CC me.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: greenlet-0.2-arm.patch
Type: application/octet-stream
Size: 2423 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20100120/1062410b/attachment.obj 

From holger at merlinux.eu  Wed Jan 20 21:20:03 2010
From: holger at merlinux.eu (holger krekel)
Date: Wed, 20 Jan 2010 21:20:03 +0100
Subject: [py-dev] [patch] greenlet on ARM/linux
In-Reply-To: <9bca96021001200932y633eb2b5tf468b898ba03255f@mail.gmail.com>
References: <9bca96021001200925m36e62d31s51f06e46e6b13535@mail.gmail.com>
	<9bca96021001200928u12b21c42rdcd507bf9100343@mail.gmail.com>
	<9bca96021001200932y633eb2b5tf468b898ba03255f@mail.gmail.com>
Message-ID: <20100120202003.GB30119@trillke.net>

On Wed, Jan 20, 2010 at 18:32 +0100, W-Mark Kubacki wrote:
> 2010/1/20 W-Mark Kubacki <wmark at hurrikane.de>:
> > Please find my patch attached.
> 
> Here comes the attachment. Sorry.

Very cool but i am afraid greenlet is not distributed with the 
py lib for a longer time now. So you need to contact other people - 
there was Bob Ippolito and others who did releases.  If you 
want to grab it and release a new "greenlet" yourself that 
could work and many people would be happy i guess, myself included. 

cheers,
holger

From holger at merlinux.eu  Sat Jan 23 00:43:01 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 23 Jan 2010 00:43:01 +0100
Subject: [py-dev] always call teardownX even if setupX fails?
Message-ID: <20100122234301.GX30119@trillke.net>

Hi all, (cross-post, beware)

i'd appreciate some feedback regarding a decision related to this issue: 
http://bitbucket.org/hpk42/py-trunk/issue/78/
where Jeff Stearns suggests to call teardown_module in any case. 

To summarize here, please consider this:

    def setup_module(mod):
        ...

    def teardown_module(mod):
        ...

Currently teardown_module will not be called if setup_module raises
an error.  This is consistent with how nosetests and unittest.py behave
(although unitttest doesn't yet have setup_module/class, but it has
setUp/tearDown).

For py.test we could easily change it such that teardown_module is called 
independently if the call to setup_module succeeded.  The same would be 
true for setup_class/teardown_class and setup_method/teardown_method pairs.  
The rationale behind this is that setup_XYZ may set up several resources
and fail somewhere in between.  Not calling teardown_XYZ leaves 
resources unfinalized, potentially causing test setup failures in other test
modules (this is what happend to Jeff). 

Do you think it would actually hurt to call teardown in any case? 
That might cause another error of course - with py.test you would both: 

    http://paste.pocoo.org/show/168612

Doesn't look like a blocker to me at the moment.  What do you think? 
Any objections or recommendations?  Do you regard consistency a blocker? 

Note that the whole issue is not a problem with funcargs and recent unittest: 
you usually set up exactly one funcarg in a factory and if that fails 
there usually is no reason to call teardown.  And if a function gets 
several funcargs, each successful funcarg setup will have a guaranteed call
to the finalizer even if different funcarg factory calls fail.  Moreover, 
you can always use "addfinalizer()" in a factory (similar to the recent unittest 
addition addCleanup()) which will trigger an unconditionally teardown. 

cheers,
(feel free to leave out one of the cross-posted mailing lists),
holger

-- 

From peloko45 at gmail.com  Sat Jan 23 14:45:13 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Sat, 23 Jan 2010 13:45:13 +0000
Subject: [py-dev] Local import
In-Reply-To: <20091223144216.GD3516@trillke.net>
References: <e1ac8ece0912230528s57821f4bs283bff026d0e3340@mail.gmail.com>
	<20091223144216.GD3516@trillke.net>
Message-ID: <e1ac8ece1001230545g5860624bt79657d97df718ce0@mail.gmail.com>

I was wrong since that it isn't necessary to import the source from
tests. It's better to use 'python setup.py develop' because it manages
well this problem.

"When you're installing a distribution, you can install it in develop
mode instead with python setup.py develop. Using this mode, a special
link file is created in your site-packages directory. This link points
back to the current folder or 'root package'. Any changes you make to
the software here will be reflected immediately without having to do
an install again.

When you're ready to install for good do a real install."

http://www.siafoo.net/article/77#install-vs-develop


2009/12/23 holger krekel <holger at merlinux.eu>:
> On Wed, Dec 23, 2009 at 13:28 +0000, Joan Miller wrote:
>> I'm using the next function to access to the source from tests without
>> install it (python setup.py develop). It's very usefull during
>> development so it could be added to py.
>
> If you use 'python setup.py develop' you should be able to
> import your package that you are currently working on already.
>
> Can you post an example how and from which file you use
> the posted function?
>
> cheers,
> holger
>
>
>> ------------------------
>> import os
>> import sys
>>
>> def import_local(parent='test', child='lib'):
>> ? ? """Inserts local library on 'sys.path'.
>>
>> ? ? Goes up until the root of the project (upper of 'parent' directory)
>> ? ? and inserts the 'child' directory.
>> ? ? """
>> ? ? parent_path = os.path.abspath(os.path.dirname(__file__))
>>
>> ? ? while parent in os.path.basename(parent_path):
>> ? ? ? ? parent_path = os.path.dirname(parent_path)
>>
>> ? ? sys.path.insert(0, os.path.join(parent_path, child))
>> ------------------------
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>
>
> --
>

From holger at merlinux.eu  Wed Jan 27 18:05:49 2010
From: holger at merlinux.eu (holger krekel)
Date: Wed, 27 Jan 2010 18:05:49 +0100
Subject: [py-dev] 1.2.1 planned next week
Message-ID: <20100127170549.GT6083@trillke.net>

Hi all, 

if you have anything small regarding py.test that you'd like to see addressed
please speak up. I plan to release a 1.2.1 end next week.

cheers,
holger

From holger at merlinux.eu  Wed Jan 27 18:07:45 2010
From: holger at merlinux.eu (holger krekel)
Date: Wed, 27 Jan 2010 18:07:45 +0100
Subject: [py-dev] [TIP] always call teardownX even if setupX fails?
In-Reply-To: <C801E576-C394-4BCA-A5B5-6F0FF71B3941@gmail.com>
References: <20100122234301.GX30119@trillke.net>
	<1264243919.5710.1.camel@lifeless-64>
	<C801E576-C394-4BCA-A5B5-6F0FF71B3941@gmail.com>
Message-ID: <20100127170745.GU6083@trillke.net>

Hi Rob, hi Doug,

On Sat, Jan 23, 2010 at 10:47 -0500, Doug Hellmann wrote:
>
> On Jan 23, 2010, at 5:51 AM, Robert Collins wrote:
>
>> On Sat, 2010-01-23 at 00:43 +0100, holger krekel wrote:
>>>
>>> Doesn't look like a blocker to me at the moment.  What do you think?
>>> Any objections or recommendations?  Do you regard consistency a
>>> blocker?
>>
>> Trial and testtools run tearDown unconditionally even though its
>> inconsistent with unittest. I'm a big fan of doing that, and encourage
>> you to do it in py.test.
>
> +1
>
> Any test with moderately complex external fixtures would benefit from  
> this behavior.  We use a subclass of unittest.TestCase that always calls 
> tearDown() for all of our tests at Racemi.

thanks for your feedback.  py.test will do that as well with 1.2.1 - with 
the addition that triggering "Skipped" exceptions in a setup function will 
not call teardown.

cheers,
holger

From peloko45 at gmail.com  Wed Jan 27 23:44:36 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Wed, 27 Jan 2010 22:44:36 +0000
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <20100127170549.GT6083@trillke.net>
References: <20100127170549.GT6083@trillke.net>
Message-ID: <e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>

py.cleanup is very usefull, but it also would be usefull to delete the
next directories (in bash would be):

  $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info

2010/1/27 holger krekel <holger at merlinux.eu>:
> Hi all,
>
> if you have anything small regarding py.test that you'd like to see addressed
> please speak up. I plan to release a 1.2.1 end next week.
>
> cheers,
> holger
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
>

From holger at merlinux.eu  Thu Jan 28 13:10:18 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Jan 2010 13:10:18 +0100
Subject: [py-dev] [TIP] always call teardownX even if setupX fails?
In-Reply-To: <1264627143.6394.24.camel@lifeless-64>
References: <20100122234301.GX30119@trillke.net>
	<1264243919.5710.1.camel@lifeless-64>
	<C801E576-C394-4BCA-A5B5-6F0FF71B3941@gmail.com>
	<20100127170745.GU6083@trillke.net>
	<1264627143.6394.24.camel@lifeless-64>
Message-ID: <20100128121018.GY6083@trillke.net>

On Thu, Jan 28, 2010 at 08:19 +1100, Robert Collins wrote:
> On Wed, 2010-01-27 at 18:07 +0100, holger krekel wrote:
> > 
> > > Any test with moderately complex external fixtures would benefit
> > from  
> > > this behavior.  We use a subclass of unittest.TestCase that always
> > calls 
> > > tearDown() for all of our tests at Racemi.
> > 
> > thanks for your feedback.  py.test will do that as well with 1.2.1 -
> > with 
> > the addition that triggering "Skipped" exceptions in a setup function
> > will 
> > not call teardown.
> 
> Why not?
> 
> Consider:
> 
> setUp:
>    self.foo = get_foo()
>    if not isinstance(self.foo, TestableThing):
>        raise TestSkipped()
> 
> Why should this /not/ call tearDown ?

not calling teardown seemed slightly easier to implement ... i can work
a bit harder though :) 

However, I haven't see your example pattern with py.test usages yet.  
Is this a an example from actual code? 

And if so do you have have and use it in setup_module and setup_class - alike 
methods? 

cheers,
holger

From holger at merlinux.eu  Thu Jan 28 13:54:54 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Jan 2010 13:54:54 +0100
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
Message-ID: <20100128125454.GC6083@trillke.net>

On Wed, Jan 27, 2010 at 22:44 +0000, Joan Miller wrote:
> py.cleanup is very usefull, but it also would be usefull to delete the
> next directories (in bash would be):
> 
>   $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info

i see how this can make sense.  Any idea how/if this should
be made configurable?  In my case *.egg-info as a general
to-be-removed pattern would make sense, i guess. 

Hum, would "py.cleanup -a" (aka cleanup including all 
typically setup.py-generated files) make sense? 
I also guess that removing "$py.class" for 
jython-generated classfiles also makes sense. 

cheers,
holger


 
> 2010/1/27 holger krekel <holger at merlinux.eu>:
> > Hi all,
> >
> > if you have anything small regarding py.test that you'd like to see addressed
> > please speak up. I plan to release a 1.2.1 end next week.
> >
> > cheers,
> > holger
> > _______________________________________________
> > 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
> 

-- 

From holger at merlinux.eu  Thu Jan 28 14:31:16 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Jan 2010 14:31:16 +0100
Subject: [py-dev] [TIP] always call teardownX even if setupX fails?
In-Reply-To: <1264682821.24790.8.camel@lifeless-64>
References: <20100122234301.GX30119@trillke.net>
	<1264243919.5710.1.camel@lifeless-64>
	<C801E576-C394-4BCA-A5B5-6F0FF71B3941@gmail.com>
	<20100127170745.GU6083@trillke.net>
	<1264627143.6394.24.camel@lifeless-64>
	<20100128121018.GY6083@trillke.net>
	<1264682821.24790.8.camel@lifeless-64>
Message-ID: <20100128133116.GE6083@trillke.net>

On Thu, Jan 28, 2010 at 23:47 +1100, Robert Collins wrote:
> On Thu, 2010-01-28 at 13:10 +0100, holger krekel wrote:
> > 
> > 
> > not calling teardown seemed slightly easier to implement ... i can
> > work
> > a bit harder though :) 
> > 
> > However, I haven't see your example pattern with py.test usages yet.  
> > Is this a an example from actual code? 
> 
> Broadly yes. Usually seen more like this in fact:
> 
> class A
>    setUp(): does stuff
> 
> class B(A):
>    setUp(): check if we should skip

If you can you'd probably first try to see if to skip and then 
call the base class' setUp(), though.  Anyway, ... 
 
> > And if so do you have have and use it in setup_module and setup_class
> > - alike 
> > methods?
> 
> I don't use such methods, so no (see prior conversation about decoupling
> resources etc).

... these cases were what seemed complicated to me. 
However, it turned out, my previous implementation was buggy anyway! 
So now there is no special casing for Skip anymore and teardown gets called
in all cases - and i also refined the "setup_module/class" calling to  
only happen exactly once (before they'd be happen multiple times for each
test if they raised an error).  Also added two functional and one unit-test
and hope things are settled now :) 

many thanks for your feedback and insistance on clarity here! 

cheers,
holger

From peloko45 at gmail.com  Thu Jan 28 19:11:40 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Thu, 28 Jan 2010 18:11:40 +0000
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <20100128125454.GC6083@trillke.net>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
	<20100128125454.GC6083@trillke.net>
Message-ID: <e1ac8ece1001281011k12243cd9y11e524deb893d4d6@mail.gmail.com>

2010/1/28 holger krekel <holger at merlinux.eu>:
> On Wed, Jan 27, 2010 at 22:44 +0000, Joan Miller wrote:
>> py.cleanup is very usefull, but it also would be usefull to delete the
>> next directories (in bash would be):
>>
>> ? $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info
>
> i see how this can make sense. ?Any idea how/if this should
> be made configurable? ?In my case *.egg-info as a general
> to-be-removed pattern would make sense, i guess.
I agree into a general pattern to delete the eggs info.

> Hum, would "py.cleanup -a" (aka cleanup including all
> typically setup.py-generated files) make sense?
> I also guess that removing "$py.class" for
> jython-generated classfiles also makes sense.
It's ok, at least for me

From Ronny.Pfannschmidt at gmx.de  Thu Jan 28 23:24:03 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Thu, 28 Jan 2010 23:24:03 +0100
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <e1ac8ece1001281011k12243cd9y11e524deb893d4d6@mail.gmail.com>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
	<20100128125454.GC6083@trillke.net>
	<e1ac8ece1001281011k12243cd9y11e524deb893d4d6@mail.gmail.com>
Message-ID: <1264717443.8246.0.camel@localhost>

On Thu, 2010-01-28 at 18:11 +0000, Joan Miller wrote:
> 2010/1/28 holger krekel <holger at merlinux.eu>:
> > On Wed, Jan 27, 2010 at 22:44 +0000, Joan Miller wrote:
> >> py.cleanup is very usefull, but it also would be usefull to delete the
> >> next directories (in bash would be):
> >>
> >>   $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info
> >
> > i see how this can make sense.  Any idea how/if this should
> > be made configurable?  In my case *.egg-info as a general
> > to-be-removed pattern would make sense, i guess.
> I agree into a general pattern to delete the eggs info.
its actually more tricky, as setup.py develop needs them
> 
> > Hum, would "py.cleanup -a" (aka cleanup including all
> > typically setup.py-generated files) make sense?
> > I also guess that removing "$py.class" for
> > jython-generated classfiles also makes sense.
> It's ok, at least for me
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev


From Adam.Schmalhofer at gmx.de  Fri Jan 29 00:00:13 2010
From: Adam.Schmalhofer at gmx.de (Adam)
Date: Fri, 29 Jan 2010 00:00:13 +0100
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <1264717443.8246.0.camel@localhost>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
	<20100128125454.GC6083@trillke.net>
	<e1ac8ece1001281011k12243cd9y11e524deb893d4d6@mail.gmail.com>
	<1264717443.8246.0.camel@localhost>
Message-ID: <20100129000013.1d80031f@deepthought>

Ronny Pfannschmidt wrote:

> On Thu, 2010-01-28 at 18:11 +0000, Joan Miller wrote:
> > 2010/1/28 holger krekel <holger at merlinux.eu>:
> > > On Wed, Jan 27, 2010 at 22:44 +0000, Joan Miller wrote:
> > >> py.cleanup is very usefull, but it also would be usefull to delete the
> > >> next directories (in bash would be):
> > >>
> > >>   $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info
> > >
> > > i see how this can make sense.  Any idea how/if this should
> > > be made configurable?  In my case *.egg-info as a general
> > > to-be-removed pattern would make sense, i guess.
> > I agree into a general pattern to delete the eggs info.
> its actually more tricky, as setup.py develop needs them

I think it is harmless, as distribute is going to delete the directory
on setup.py clean:

http://bitbucket.org/tarek/distribute/issue/122/setuppy-clean-should-delete-sourcestxt

In the future it might be better to call setup.py clean on every
setup.py instead of deleting the directory directly.

--Adam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20100129/9e69bf23/attachment.pgp 

From Ronny.Pfannschmidt at gmx.de  Fri Jan 29 01:05:01 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Fri, 29 Jan 2010 01:05:01 +0100
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <20100129000013.1d80031f@deepthought>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
	<20100128125454.GC6083@trillke.net>
	<e1ac8ece1001281011k12243cd9y11e524deb893d4d6@mail.gmail.com>
	<1264717443.8246.0.camel@localhost>
	<20100129000013.1d80031f@deepthought>
Message-ID: <1264723501.8246.2.camel@localhost>

On Fri, 2010-01-29 at 00:00 +0100, Adam wrote:
> Ronny Pfannschmidt wrote:
> 
> > On Thu, 2010-01-28 at 18:11 +0000, Joan Miller wrote:
> > > 2010/1/28 holger krekel <holger at merlinux.eu>:
> > > > On Wed, Jan 27, 2010 at 22:44 +0000, Joan Miller wrote:
> > > >> py.cleanup is very usefull, but it also would be usefull to delete the
> > > >> next directories (in bash would be):
> > > >>
> > > >>   $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info
> > > >
> > > > i see how this can make sense.  Any idea how/if this should
> > > > be made configurable?  In my case *.egg-info as a general
> > > > to-be-removed pattern would make sense, i guess.
> > > I agree into a general pattern to delete the eggs info.
> > its actually more tricky, as setup.py develop needs them
> 
> I think it is harmless, as distribute is going to delete the directory
> on setup.py clean:
> 
the idea is not to break packages that got enabled within the users home
via setup.py develop --user

it does harm, as it would break features like entrypoints for those

> http://bitbucket.org/tarek/distribute/issue/122/setuppy-clean-should-delete-sourcestxt
> 
> In the future it might be better to call setup.py clean on every
> setup.py instead of deleting the directory directly.
> 
> --Adam


From peloko45 at gmail.com  Sun Jan 31 18:26:32 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Sun, 31 Jan 2010 17:26:32 +0000
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <20100127170549.GT6083@trillke.net>
References: <20100127170549.GT6083@trillke.net>
Message-ID: <e1ac8ece1001310926g3ee4ecd3h70a63c55fbccec94@mail.gmail.com>

There is a decorator used in nose to manage errors that should be
raised, which makes it more clear:

http://code.google.com/p/python-nose/source/browse/nose/tools.py#59


2010/1/27 holger krekel <holger at merlinux.eu>:
> Hi all,
>
> if you have anything small regarding py.test that you'd like to see addressed
> please speak up. I plan to release a 1.2.1 end next week.
>

From wmark at hurrikane.de  Sun Jan 31 18:39:10 2010
From: wmark at hurrikane.de (W-Mark Kubacki)
Date: Sun, 31 Jan 2010 18:39:10 +0100
Subject: [py-dev] [patch] greenlet on ARM/linux
In-Reply-To: <20100120202003.GB30119@trillke.net>
References: <9bca96021001200925m36e62d31s51f06e46e6b13535@mail.gmail.com> 
	<9bca96021001200928u12b21c42rdcd507bf9100343@mail.gmail.com> 
	<9bca96021001200932y633eb2b5tf468b898ba03255f@mail.gmail.com> 
	<20100120202003.GB30119@trillke.net>
Message-ID: <9bca96021001310939u974e59aub0e237d824e91474@mail.gmail.com>

2010/1/20 holger krekel <holger at ...>:
> [...]
> Very cool but i am afraid greenlet is not distributed with the
> py lib for a longer time now. So you need to contact other people -
> there was Bob Ippolito and others who did releases. ?If you
> want to grab it and release a new "greenlet" yourself that
> could work and many people would be happy i guess, myself included.

If it is okay with Bob you could move Greenlets to Github (I am
"wmark" there), so users can at least post issues and patches and
create a fork if needed. I will not promise anything, but am willing
to test and verify patches at least on different architectures.

-- 
Mark

From holger at merlinux.eu  Sun Jan 31 21:21:23 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 31 Jan 2010 21:21:23 +0100
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <e1ac8ece1001310926g3ee4ecd3h70a63c55fbccec94@mail.gmail.com>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001310926g3ee4ecd3h70a63c55fbccec94@mail.gmail.com>
Message-ID: <20100131202123.GN6083@trillke.net>

Hi Joan, 

there already is "py.test.raises()" to do it dynamically. 
I am slightly hesitant to add a declarative way.   

is a decorator the only way how nose supports 
"expected-to-raise" assertions?

cheers,
holger

On Sun, Jan 31, 2010 at 17:26 +0000, Joan Miller wrote:
> There is a decorator used in nose to manage errors that should be
> raised, which makes it more clear:
> 
> http://code.google.com/p/python-nose/source/browse/nose/tools.py#59
> 
> 
> 2010/1/27 holger krekel <holger at merlinux.eu>:
> > Hi all,
> >
> > if you have anything small regarding py.test that you'd like to see addressed
> > please speak up. I plan to release a 1.2.1 end next week.
> >
> 

-- 

From peloko45 at gmail.com  Sun Jan 31 21:44:43 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Sun, 31 Jan 2010 20:44:43 +0000
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <20100131202123.GN6083@trillke.net>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001310926g3ee4ecd3h70a63c55fbccec94@mail.gmail.com>
	<20100131202123.GN6083@trillke.net>
Message-ID: <e1ac8ece1001311244n988a224nbde2c95314baf46@mail.gmail.com>

2010/1/31 holger krekel <holger at merlinux.eu>:
> Hi Joan,
>
> there already is "py.test.raises()" to do it dynamically.
> I am slightly hesitant to add a declarative way.
>
> is a decorator the only way how nose supports
> "expected-to-raise" assertions?
It doesn't the only way. That decorator has been added into a one of
last releases.

>
> cheers,
> holger
>
> On Sun, Jan 31, 2010 at 17:26 +0000, Joan Miller wrote:
>> There is a decorator used in nose to manage errors that should be
>> raised, which makes it more clear:
>>
>> http://code.google.com/p/python-nose/source/browse/nose/tools.py#59
>>
>>
>> 2010/1/27 holger krekel <holger at merlinux.eu>:
>> > Hi all,
>> >
>> > if you have anything small regarding py.test that you'd like to see addressed
>> > please speak up. I plan to release a 1.2.1 end next week.
>> >
>>
>
> --
>

From peloko45 at gmail.com  Mon Feb  1 13:19:13 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Mon, 1 Feb 2010 12:19:13 +0000
Subject: [py-dev] Tear down into a class
Message-ID: <e1ac8ece1002010419q42fac59n1041aa3b8709d350@mail.gmail.com>

Is possible to have a tear down function at class-level?

From peloko45 at gmail.com  Mon Feb  1 13:22:28 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Mon, 1 Feb 2010 12:22:28 +0000
Subject: [py-dev] setuptools
Message-ID: <e1ac8ece1002010422p3bbc9bbcu9247ec7153c7ba9c@mail.gmail.com>

Are there plans for the integration with setuptools/distribute?

So I would that py.test were run using *python setup.py py.test* or
anything so, as is made with nosetools

From holger at merlinux.eu  Mon Feb  1 15:30:15 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 1 Feb 2010 15:30:15 +0100
Subject: [py-dev] setuptools
In-Reply-To: <e1ac8ece1002010422p3bbc9bbcu9247ec7153c7ba9c@mail.gmail.com>
References: <e1ac8ece1002010422p3bbc9bbcu9247ec7153c7ba9c@mail.gmail.com>
Message-ID: <20100201143015.GZ6083@trillke.net>

On Mon, Feb 01, 2010 at 12:22 +0000, Joan Miller wrote:
> Are there plans for the integration with setuptools/distribute?
> 
> So I would that py.test were run using *python setup.py py.test* or
> anything so, as is made with nosetools

I've seen some discussions, haven't played much with it myself yet. 
Googled a bit and came up with the below patch to one of my 
(non-py) packages.  With it I could successfully do:

    python setup.py test # will run "py.test" 

and it would also take care to temporarily install "py" just for the 
testing and not as a general dependency.  Happy to hear if this works
for you and others as well. 

cheers,
holger


diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -3,6 +3,7 @@ if sys.version_info >= (3,0):
     from distribute_setup import use_setuptools
     use_setuptools()
 from setuptools import setup
+from setuptools.command.test import test

 long_description = """
 ciss: code-centered single-file "ISSUES.txt" issue tracking
         license='MIT license',
         platforms=['unix', 'linux', 'osx', 'cygwin', 'win32'],
         author='holger krekel',
         author_email='holger at merlinux.eu',
+        cmdclass = {'test': PyTest},
+        tests_require = ['py'],
         entry_points={'console_scripts': [
             'ciss = ciss:main',
         ]},
@@ -39,6 +42,15 @@ def main():
         zip_safe=False,
     )

+class PyTest(test):
+    user_options = []
+    def initialize_options(self):
+        test.initialize_options(self)
+        self.test_suite = "."
+    def run_tests(self):
+        import py
+        py.cmdline.pytest(['.'])
+
 if __name__ == '__main__':
     main()


From peloko45 at gmail.com  Mon Feb  1 17:14:12 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Mon, 1 Feb 2010 16:14:12 +0000
Subject: [py-dev] setuptools
In-Reply-To: <20100201143015.GZ6083@trillke.net>
References: <e1ac8ece1002010422p3bbc9bbcu9247ec7153c7ba9c@mail.gmail.com>
	<20100201143015.GZ6083@trillke.net>
Message-ID: <e1ac8ece1002010814m749d217cka635b542564d0f28@mail.gmail.com>

The ideal would be to pass a collector to the option 'test_suite' in
setuptools, i.e. for nose [1] is used:

  test_suite = "nose.collector",

This way has been added too to Pip [2]. Here the info. about that option [3]


[1] http://somethingaboutorange.com/mrl/projects/nose/0.11.1/setuptools_integration.html
[2] http://ericholscher.com/blog/2009/nov/5/adding-testing-pip/
[3] http://peak.telecommunity.com/DevCenter/setuptools#test


2010/2/1 holger krekel <holger at merlinux.eu>:
> On Mon, Feb 01, 2010 at 12:22 +0000, Joan Miller wrote:
>> Are there plans for the integration with setuptools/distribute?
>>
>> So I would that py.test were run using *python setup.py py.test* or
>> anything so, as is made with nosetools
>
> I've seen some discussions, haven't played much with it myself yet.
> Googled a bit and came up with the below patch to one of my
> (non-py) packages. ?With it I could successfully do:
>
> ? ?python setup.py test # will run "py.test"
>
> and it would also take care to temporarily install "py" just for the
> testing and not as a general dependency. ?Happy to hear if this works
> for you and others as well.
>
> cheers,
> holger
>
>
> diff --git a/setup.py b/setup.py
> --- a/setup.py
> +++ b/setup.py
> @@ -3,6 +3,7 @@ if sys.version_info >= (3,0):
> ? ? from distribute_setup import use_setuptools
> ? ? use_setuptools()
> ?from setuptools import setup
> +from setuptools.command.test import test
>
> ?long_description = """
> ?ciss: code-centered single-file "ISSUES.txt" issue tracking
> ? ? ? ? license='MIT license',
> ? ? ? ? platforms=['unix', 'linux', 'osx', 'cygwin', 'win32'],
> ? ? ? ? author='holger krekel',
> ? ? ? ? author_email='holger at merlinux.eu',
> + ? ? ? ?cmdclass = {'test': PyTest},
> + ? ? ? ?tests_require = ['py'],
> ? ? ? ? entry_points={'console_scripts': [
> ? ? ? ? ? ? 'ciss = ciss:main',
> ? ? ? ? ]},
> @@ -39,6 +42,15 @@ def main():
> ? ? ? ? zip_safe=False,
> ? ? )
>
> +class PyTest(test):
> + ? ?user_options = []
> + ? ?def initialize_options(self):
> + ? ? ? ?test.initialize_options(self)
> + ? ? ? ?self.test_suite = "."
> + ? ?def run_tests(self):
> + ? ? ? ?import py
> + ? ? ? ?py.cmdline.pytest(['.'])
> +
> ?if __name__ == '__main__':
> ? ? main()
>
>

From holger at merlinux.eu  Mon Feb  1 17:30:21 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 1 Feb 2010 17:30:21 +0100
Subject: [py-dev] setuptools
In-Reply-To: <e1ac8ece1002010814m749d217cka635b542564d0f28@mail.gmail.com>
References: <e1ac8ece1002010422p3bbc9bbcu9247ec7153c7ba9c@mail.gmail.com>
	<20100201143015.GZ6083@trillke.net>
	<e1ac8ece1002010814m749d217cka635b542564d0f28@mail.gmail.com>
Message-ID: <20100201163021.GC6083@trillke.net>

Hi Joan,

On Mon, Feb 01, 2010 at 16:14 +0000, Joan Miller wrote:
> The ideal would be to pass a collector to the option 'test_suite' in
> setuptools, i.e. for nose [1] is used:
> 
>   test_suite = "nose.collector",
> 
> This way has been added too to Pip [2]. Here the info. about that option [3]

This expects a unittest loader which py.test doesn't provide (yet).  Your [2] also 
has some critical comments btw - and in general i think the current 
"test-during-setup/install-time" needs more thought.  I'd rather fancy a 
mechanism to run a script with some developer-defined arguments 
and to allow specification of "packages needed for testing". 

On a practical note, did you try out the solution i sketched?
It basically implements exactly that in few lines of code
with the current setuptools/distribute infrastructure. 

If anybody wants to chime in - feel free to :) 

holger

> 
> [1] http://somethingaboutorange.com/mrl/projects/nose/0.11.1/setuptools_integration.html
> [2] http://ericholscher.com/blog/2009/nov/5/adding-testing-pip/
> [3] http://peak.telecommunity.com/DevCenter/setuptools#test
> 
> 
> 2010/2/1 holger krekel <holger at merlinux.eu>:
> > On Mon, Feb 01, 2010 at 12:22 +0000, Joan Miller wrote:
> >> Are there plans for the integration with setuptools/distribute?
> >>
> >> So I would that py.test were run using *python setup.py py.test* or
> >> anything so, as is made with nosetools
> >
> > I've seen some discussions, haven't played much with it myself yet.
> > Googled a bit and came up with the below patch to one of my
> > (non-py) packages. ?With it I could successfully do:
> >
> > ? ?python setup.py test # will run "py.test"
> >
> > and it would also take care to temporarily install "py" just for the
> > testing and not as a general dependency. ?Happy to hear if this works
> > for you and others as well.
> >
> > cheers,
> > holger
> >
> >
> > diff --git a/setup.py b/setup.py
> > --- a/setup.py
> > +++ b/setup.py
> > @@ -3,6 +3,7 @@ if sys.version_info >= (3,0):
> > ? ? from distribute_setup import use_setuptools
> > ? ? use_setuptools()
> > ?from setuptools import setup
> > +from setuptools.command.test import test
> >
> > ?long_description = """
> > ?ciss: code-centered single-file "ISSUES.txt" issue tracking
> > ? ? ? ? license='MIT license',
> > ? ? ? ? platforms=['unix', 'linux', 'osx', 'cygwin', 'win32'],
> > ? ? ? ? author='holger krekel',
> > ? ? ? ? author_email='holger at merlinux.eu',
> > + ? ? ? ?cmdclass = {'test': PyTest},
> > + ? ? ? ?tests_require = ['py'],
> > ? ? ? ? entry_points={'console_scripts': [
> > ? ? ? ? ? ? 'ciss = ciss:main',
> > ? ? ? ? ]},
> > @@ -39,6 +42,15 @@ def main():
> > ? ? ? ? zip_safe=False,
> > ? ? )
> >
> > +class PyTest(test):
> > + ? ?user_options = []
> > + ? ?def initialize_options(self):
> > + ? ? ? ?test.initialize_options(self)
> > + ? ? ? ?self.test_suite = "."
> > + ? ?def run_tests(self):
> > + ? ? ? ?import py
> > + ? ? ? ?py.cmdline.pytest(['.'])
> > +
> > ?if __name__ == '__main__':
> > ? ? main()
> >
> >
> 

-- 

From holger at merlinux.eu  Tue Feb  2 11:08:06 2010
From: holger at merlinux.eu (holger krekel)
Date: Tue, 2 Feb 2010 11:08:06 +0100
Subject: [py-dev] Tear down into a class
In-Reply-To: <e1ac8ece1002010419q42fac59n1041aa3b8709d350@mail.gmail.com>
References: <e1ac8ece1002010419q42fac59n1041aa3b8709d350@mail.gmail.com>
Message-ID: <20100202100806.GE6083@trillke.net>

On Mon, Feb 01, 2010 at 12:19 +0000, Joan Miller wrote:
> Is possible to have a tear down function at class-level?

http://codespeak.net/py/dist/test/xunit_setup.html

H.

From holger at merlinux.eu  Sat Feb  6 11:09:06 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 6 Feb 2010 11:09:06 +0100
Subject: [py-dev] new py.cleanup options
Message-ID: <20100206100906.GE6083@trillke.net>

Hi all, 

for those interested (related to the earlier py.cleanup discussion) i 
just committed some improvements.  Options now work like this: 

    py.cleanup     # remove "*.pyc" and "*$py.class" (jython) files
    py.cleanup -e .swp -e .cache # also remove files with these extensions
    py.cleanup -s  # remove "build" and "dist" directory next to setup.py files
    py.cleanup -d  # also remove empty directories
    py.cleanup -a  # synonym for "-s -d -e 'pip-log.txt'"
    py.cleanup -n  # dry run, only show what would be removed

If you don't specify path(s), the current working dir will be used. 
Note that i don't remove "*egg-info" directories - it would
break "python setup.py develop" and i'd like to keep the py.cleanup
command safe in this regard. 

If you like to play, use easy_install or pip-install on:

    http://codespeak.net/~hpk/py-1.2.0post1.tar.gz

cheers,
holger

From holger at merlinux.eu  Sun Feb  7 17:55:04 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 7 Feb 2010 17:55:04 +0100
Subject: [py-dev] basic py.test tutorial - draft
Message-ID: <20100207165504.GK6083@trillke.net>

Hi all, 

i've just completed my draft for the Pycon tutorial 
"rapid multi-purpose testing with py.test". 

see here for PDF and example directories:

    hg clone http://bitbucket.org/hpk42/pytest-tutorial1/

or just grab the PDF here:

    http://bitbucket.org/hpk42/pytest-tutorial1/raw/5a8deeba9184/pytest-basic.pdf

If anybody feels like walking through it and sending 
me feedback, that'd be much appreciated.  It covers 

- basic usage
- marking and skipping
- funcargs 
- the "mysetup" pattern 

in successive examples. 

cheers,
holger

From holger at merlinux.eu  Mon Feb  8 17:37:31 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 8 Feb 2010 17:37:31 +0100
Subject: [py-dev] py.test 1.2.1 released
Message-ID: <20100208163731.GM6083@trillke.net>

Hi all, 

i just released py-1.2.1 - thanks for all your feedback 
and suggestions here and on IRC.  The announcement and changes: 

    http://codespeak.net/py/dist/announce/release-1.2.1.html

main fixes and improvements: 

* --funcargs [testpath]  will show available builtin- and project funcargs.
* display a short and concise traceback if funcarg lookup fails.
* early-load "conftest.py" files in non-dot first-level sub directories.
* --tb=line will print a single line for each failing test (issue67)
* py.cleanup has a number of new options, cleans setup.py related files
* always call python-level teardown functions even if setup failed (issue78).

a detailed CHANGELOG is inlined below. 

cheers,
holger

P.S.: After Pycon US i am going to be offline until beginning april.
Looking forward to it, btw! :)

Changes between 1.2.1 and 1.2.0
=====================================

- refined usage and options for "py.cleanup"::

    py.cleanup     # remove "*.pyc" and "*$py.class" (jython) files
    py.cleanup -e .swp -e .cache # also remove files with these extensions
    py.cleanup -s  # remove "build" and "dist" directory next to setup.py files
    py.cleanup -d  # also remove empty directories 
    py.cleanup -a  # synonym for "-s -d -e 'pip-log.txt'"
    py.cleanup -n  # dry run, only show what would be removed

- add a new option "py.test --funcargs" which shows available funcargs 
  and their help strings (docstrings on their respective factory function) 
  for a given test path

- display a short and concise traceback if a funcarg lookup fails 

- early-load "conftest.py" files in non-dot first-level sub directories. 
  allows to conveniently keep and access test-related options in a ``test`` 
  subdir and still add command line options. 

- fix issue67: new super-short traceback-printing option: "--tb=line" will print a single line for each failing (python) test indicating its filename, lineno and the failure value

- fix issue78: always call python-level teardown functions even if the according
  setup failed.  This includes refinements for calling setup_module/class
  functions which will now only be called once instead of the previous behaviour
  where they'd be called multiple times if they raise an exception (including a
  Skipped exception).  Any exception will be re-corded and associated with all
  tests in the according module/class scope.

- fix issue63: assume <40 columns to be a bogus terminal width, default to 80

- fix pdb debugging to be in the correct frame on raises-related errors 

- update apipkg.py to fix an issue where recursive imports might
  unnecessarily break importing 

- fix plugin links 


From holger at merlinux.eu  Fri Feb 12 13:57:16 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 12 Feb 2010 13:57:16 +0100
Subject: [py-dev] testrun.org, hudson, py.test
Message-ID: <20100212125716.GX6083@trillke.net>

hi all, 

FYI i sent a mail regarding a new site http://testrun.org 
to the testing-in-python list, see below.  Of course the contained 
offer applies to you here as well - may be useful for people using 
py.test to look into how it's configured for Hudson, a popular
CI server written in Java. 

cheers,
holger

----- Forwarded message from holger krekel <holger at merlinux.eu> -----

Date: Wed, 10 Feb 2010 15:02:38 +0100
From: holger krekel <holger at merlinux.eu>
To: Testing in Python <testing-in-python at lists.idyll.org>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Subject: [TIP] starting testrun.org for testing in python

Hi all, 

This year i plan to work a lot on testing and Python - and one of my plans
is to build up some collective computing resources for testing.  Not tied to 
any particular testing tool or practise but rather to Continous Integration
methods. 

Here is the practical start of this effort::

    http://testrun.org

It doesn't have a fancy website such as Snakebite - in fact i really try 
to outcompete Titus on KISS principles here and just start operating it :) 

Note that I am using Hudson to get to know the current state of the art - 
i realize it's not a perfect fit for Python.  It does have tons of plugins
though and is a standard in the Java world (guess-what i actually just did 
some open-source strategy consulting in a Java shop and thus dived in :).

We can add more jobs and views to it and if anyone here has experience
and wants to help - i grant admin rights easily.  Particularly since i am
away after Pycon for 6 weeks.  It'd also be great if some Snakebite resources
or other resources could be added - just contact me or grab me at Pycon. 
It should not take more than 5 minutes to set a new node.  Given
interest i'll setup a mailing list where we discuss matters further -
otherwise i presume it's ok to communicate a bit about this here. 

Any feedback and ideas welcome. And again, this is *not* py.test specific 
although i certainly want to make py.test integrate nicely.  

cheers,
holger

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


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

-- 

From pontus.astrom at businessecurity.com  Fri Feb 12 14:32:42 2010
From: pontus.astrom at businessecurity.com (=?ISO-8859-1?Q?Pontus_=C5str=F6m?=)
Date: Fri, 12 Feb 2010 14:32:42 +0100
Subject: [py-dev] Acceptance testing with py.test
Message-ID: <4B75587A.2060208@businessecurity.com>

Hi,

I'm considering a plugin for doing acceptance testing with py.test. The 
core idea is to mimic the behaviour of Concordion 
(http://concordion.org) with respect to visual effects and reports, but 
use a python engine. The python libs I am considering are py.test for 
running tests and genshi for xml instrumentation.

Then, to get a polished plugin some code need to be written; a py.test 
plugin for test collection and reporting, and a utility library for 
easing genshi xml insturmentation.

Well, the reason for this explanation is to see if anybody out there has 
some input regarding the idea, or maybe know of some useful libs or 
approaches to achieve the aim, which btw. is to obtain efficient, 
readable, executable acceptance tests connected to requirements. Read 
more about this aim on the Concordion website.

Cheers, Pontus


From holger at merlinux.eu  Fri Feb 12 22:23:47 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 12 Feb 2010 22:23:47 +0100
Subject: [py-dev] Acceptance testing with py.test
In-Reply-To: <4B75587A.2060208@businessecurity.com>
References: <4B75587A.2060208@businessecurity.com>
Message-ID: <20100212212347.GD6083@trillke.net>

Hi Pontus,

On Fri, Feb 12, 2010 at 14:32 +0100, Pontus ?str?m wrote:
> I'm considering a plugin for doing acceptance testing with py.test. The 
> core idea is to mimic the behaviour of Concordion 
> (http://concordion.org) with respect to visual effects and reports, but 
> use a python engine. The python libs I am considering are py.test for 
> running tests and genshi for xml instrumentation.

I think that's a good plan :) 

> Then, to get a polished plugin some code need to be written; a py.test 
> plugin for test collection and reporting, and a utility library for 
> easing genshi xml insturmentation.
> 
> Well, the reason for this explanation is to see if anybody out there has 
> some input regarding the idea, or maybe know of some useful libs or 
> approaches to achieve the aim, which btw. is to obtain efficient, 
> readable, executable acceptance tests connected to requirements. Read 
> more about this aim on the Concordion website.

Myself, i haven't too much acceptance testing with non-python domains. 
I hear that Ruby is strong with domain-specific testing but haven't
checked on things myself yet.  As far as giving you some ideas 
on how the py.test plugin side might look like i hope that Ronny
Pfannschmidt or Ali Afshar can provide a pointer to their code
for driving tests from yaml definitions as a starting point. 

cheers,
holger

From Ronny.Pfannschmidt at gmx.de  Sat Feb 13 13:17:40 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sat, 13 Feb 2010 13:17:40 +0100
Subject: [py-dev] pytest codecheck plugin, request for comments/review
Message-ID: <1266063460.9546.119.camel@localhost>

Hi,

i just finished the initial version of my pytest-codecheck plugin

its availiable at
http://bitbucket.org/RonnyPfannschmidt/pytest-pycheckers/


currently it is not configurable, it just runs pep8 based on the
moinmoin settings and pyflakes

it lacks some idea of caching runs, it should auto-skip in case of
codecheck-mtime > code-mtime

regards Ronny


From holger at merlinux.eu  Sat Feb 13 13:27:13 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 13 Feb 2010 13:27:13 +0100
Subject: [py-dev] pytest codecheck plugin, request for comments/review
In-Reply-To: <1266063460.9546.119.camel@localhost>
References: <1266063460.9546.119.camel@localhost>
Message-ID: <20100213122713.GH6083@trillke.net>

On Sat, Feb 13, 2010 at 13:17 +0100, Ronny Pfannschmidt wrote:
> Hi,
> 
> i just finished the initial version of my pytest-codecheck plugin

cool!
 
> its availiable at
> http://bitbucket.org/RonnyPfannschmidt/pytest-pycheckers/
> 
> currently it is not configurable, it just runs pep8 based on the
> moinmoin settings and pyflakes
> 
> it lacks some idea of caching runs, it should auto-skip in case of
> codecheck-mtime > code-mtime

Or maybe do a command line option that drives/configures it? 

In any case, i think it'd be very worthwhile to 
"setup.py sdist register upload" already. 

holger

From holger at merlinux.eu  Sat Feb 13 15:08:00 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 13 Feb 2010 15:08:00 +0100
Subject: [py-dev] pytest codecheck plugin, request for comments/review
In-Reply-To: <20100213122713.GH6083@trillke.net>
References: <1266063460.9546.119.camel@localhost>
	<20100213122713.GH6083@trillke.net>
Message-ID: <20100213140800.GI6083@trillke.net>

On Sat, Feb 13, 2010 at 13:27 +0100, holger krekel wrote:
> On Sat, Feb 13, 2010 at 13:17 +0100, Ronny Pfannschmidt wrote:
> In any case, i think it'd be very worthwhile to 
> "setup.py sdist register upload" already. 

Ronny did that :) it's named pytest-codecheckers now and checks
pep8 and pflakes compliancy for any python files you point it to do.  
If you have issues just send them here, i guess. 

holger

From Ronny.Pfannschmidt at gmx.de  Sun Feb 14 00:57:05 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sun, 14 Feb 2010 00:57:05 +0100
Subject: [py-dev] Acceptance testing with py.test
In-Reply-To: <20100212212347.GD6083@trillke.net>
References: <4B75587A.2060208@businessecurity.com>
	<20100212212347.GD6083@trillke.net>
Message-ID: <1266105425.9546.145.camel@localhost>

On Fri, 2010-02-12 at 22:23 +0100, holger krekel wrote:
> Hi Pontus,
> 
> On Fri, Feb 12, 2010 at 14:32 +0100, Pontus ?str?m wrote:
> > I'm considering a plugin for doing acceptance testing with py.test. The 
> > core idea is to mimic the behaviour of Concordion 
> > (http://concordion.org) with respect to visual effects and reports, but 
> > use a python engine. The python libs I am considering are py.test for 
> > running tests and genshi for xml instrumentation.
> 
> I think that's a good plan :) 
> 
> > Then, to get a polished plugin some code need to be written; a py.test 
> > plugin for test collection and reporting, and a utility library for 
> > easing genshi xml insturmentation.
> > 
> > Well, the reason for this explanation is to see if anybody out there has 
> > some input regarding the idea, or maybe know of some useful libs or 
> > approaches to achieve the aim, which btw. is to obtain efficient, 
> > readable, executable acceptance tests connected to requirements. Read 
> > more about this aim on the Concordion website.
> 
I have some basic ideas about structuring that kind of test.

A) steped reporting, so each test reports the current step
B) collection of dependend test-items, having each test item as `step`

A requires extending the py.test reporting (but might be easy)
B requires extending the py.test test execution

Ali currently does acceptance testing for webapps using approach B.
The test collector is at
http://bitbucket.org/aafshar/glashammer-testing/src/tip/glashammer/utils/testing.py
however it currently lacks dependend tests support.

We would also like to build acceptance testing tools for pygtk,
but those seem more fit for approach A.
We would need those for more complex applications,
like http://pida.co.uk

Another interesting acceptance test approach is the way mercurial is
tested.
Its using sectioned shell scripts that can be matched with sectioned
expected output files.

I will do some more Work in those Areas after 17.03

-- Ronny

> Myself, i haven't too much acceptance testing with non-python domains. 
> I hear that Ruby is strong with domain-specific testing but haven't
> checked on things myself yet.  As far as giving you some ideas 
> on how the py.test plugin side might look like i hope that Ronny
> Pfannschmidt or Ali Afshar can provide a pointer to their code
> for driving tests from yaml definitions as a starting point. 
> 
> cheers,
> holger


From Ronny.Pfannschmidt at gmx.de  Sun Feb 14 09:06:27 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sun, 14 Feb 2010 09:06:27 +0100
Subject: [py-dev] RFC pytest metadata store plugin
Message-ID: <1266134787.28016.11.camel@localhost>

hi,

i just got a basic item for a pytest caching plugin


it would basically be a key-value store for test items/fspath items

it should provide 2 objects as funcargs/py.test namesspace items

path_meta
    store key-values for the current fspath
item_meta
    store key-values for the current test item

the need i have for such a feature is based in the speed issue of the
codecheckers plugin, in particular pep8 is slow, and should be skipped
in case of the file's mtime being less than the last run of the pep8
check and had no issues

issues i havent clearly tought about yet is how to store and where to
store

options i currently can think of are:

- xattr on the actual files/alternative streams
- a sqlite db

-- Ronny


From Ronny.Pfannschmidt at gmx.de  Sun Feb 14 09:20:06 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sun, 14 Feb 2010 09:20:06 +0100
Subject: [py-dev] how to use StdCapture().call propperly (i.e. not breaking
 py.test -s)
Message-ID: <1266135606.28016.13.camel@localhost>

hi,

currently the codecheckers breaks py.test -s,
cause the nested capture stops to work once the parent capture is gone.

-- Ronny


From schettino72 at gmail.com  Sun Feb 14 10:41:04 2010
From: schettino72 at gmail.com (Eduardo Schettino)
Date: Sun, 14 Feb 2010 17:41:04 +0800
Subject: [py-dev] RFC pytest metadata store plugin
In-Reply-To: <1266134787.28016.11.camel@localhost>
References: <1266134787.28016.11.camel@localhost>
Message-ID: <e24a65c91002140141r4945ce10o3c9e02e7948bf1f6@mail.gmail.com>

On Sun, Feb 14, 2010 at 4:06 PM, Ronny Pfannschmidt
<Ronny.Pfannschmidt at gmx.de> wrote:
> hi,
>
> i just got a basic item for a pytest caching plugin
>
>
> it would basically be a key-value store for test items/fspath items
>
> it should provide 2 objects as funcargs/py.test namesspace items
>
> path_meta
> ? ?store key-values for the current fspath
> item_meta
> ? ?store key-values for the current test item
>
> the need i have for such a feature is based in the speed issue of the
> codecheckers plugin, in particular pep8 is slow, and should be skipped
> in case of the file's mtime being less than the last run of the pep8
> check and had no issues

I solved this problem using a different tool. You might want to take a
look at "doit". it is more like a build-tool than a test runner.

http://python-doit.sourceforge.net/

Regards,
  Eduardo

From prologic at shortcircuit.net.au  Sun Feb 14 15:48:41 2010
From: prologic at shortcircuit.net.au (James Mills)
Date: Mon, 15 Feb 2010 00:48:41 +1000
Subject: [py-dev] Testing daemonize() (of sorts)
Message-ID: <e1a84d571002140648l52a6713fjfc542a05a28cd34f@mail.gmail.com>

Hi Folks,

Not sure how big this community here is, but at
the suggestion of Ronny, here's a problem I'd like
to "throw" at you:

Consider the following test for my library circuits (1):

http://bitbucket.org/prologic/circuits-dev/src/tip/tests/app/test_daemon.py

Notice how I have to externally call "python app.py <pidfile>" in order to
make the test work ? I haven't found a way to integrate the app within the
test function/module at all without errors flying widely.

The problem with the above method (although works and passes) is that
the no coverage data is picked up by the fact that "app.py" was executed
and therefore parts (or all) of the Daemon Component (2) were actually
covered.

Anyone have any suggestions or workarounds here ?

Thanks,

cheers
James

1. http://code.google.com/p/circuits/
2. http://bitbucket.org/prologic/circuits-dev/src/1e4ebb87eafc/circuits/app/__init__.py#cl-20

--
-- "Problems are solved by method"

From pontus.astrom at businessecurity.com  Mon Feb 15 08:30:04 2010
From: pontus.astrom at businessecurity.com (=?UTF-8?B?UG9udHVzIMOFc3Ryw7Zt?=)
Date: Mon, 15 Feb 2010 08:30:04 +0100
Subject: [py-dev] Acceptance testing with py.test
In-Reply-To: <1266105425.9546.145.camel@localhost>
References: <4B75587A.2060208@businessecurity.com>	
	<20100212212347.GD6083@trillke.net>
	<1266105425.9546.145.camel@localhost>
Message-ID: <4B78F7FC.3060600@businessecurity.com>

Ronny Pfannschmidt wrote:
> On Fri, 2010-02-12 at 22:23 +0100, holger krekel wrote:
>   
> I have some basic ideas about structuring that kind of test.
>
> A) steped reporting, so each test reports the current step
> B) collection of dependend test-items, having each test item as `step`
>
> A requires extending the py.test reporting (but might be easy)
> B requires extending the py.test test execution
>   
Could you just elaborate a bit on the above items and giving the 
rationale for each approach. I currently have some difficulty 
understanding what you mean.


From holger at merlinux.eu  Mon Feb 15 10:54:15 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 15 Feb 2010 10:54:15 +0100
Subject: [py-dev] RFC pytest metadata store plugin
In-Reply-To: <1266134787.28016.11.camel@localhost>
References: <1266134787.28016.11.camel@localhost>
Message-ID: <20100215095415.GQ6083@trillke.net>

On Sun, Feb 14, 2010 at 09:06 +0100, Ronny Pfannschmidt wrote:
> it would basically be a key-value store for test items/fspath items
> 
> it should provide 2 objects as funcargs/py.test namesspace items
> 
> path_meta
>     store key-values for the current fspath
> item_meta
>     store key-values for the current test item

don't think funcargs are of primary interest for this but rather other plugins
(like codecheckers) who want to useit to store information. It would also help
to implement persistence across test sessions and features like 
"run last failing tests" without having to use "--looponfailing"
from the 'python-xdist' plugin. 

> the need i have for such a feature is based in the speed issue of the
> codecheckers plugin, in particular pep8 is slow, and should be skipped
> in case of the file's mtime being less than the last run of the pep8
> check and had no issues
> 
> issues i havent clearly tought about yet is how to store and where to
> store
> 
> options i currently can think of are:
> 
> - xattr on the actual files/alternative streams
> - a sqlite db

IMHO neither - rather in a directory in the plain filesystem as 
this should work on any python and operating system. 
The main issue issues i see are

- how to determine the caching-data directory 
- how to provide a minimal interface to access and manipulate it. 

cheers
holger

From holger at merlinux.eu  Mon Feb 15 11:11:57 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 15 Feb 2010 11:11:57 +0100
Subject: [py-dev] Acceptance testing with py.test
In-Reply-To: <4B78F7FC.3060600@businessecurity.com>
References: <4B75587A.2060208@businessecurity.com>
	<20100212212347.GD6083@trillke.net>
	<1266105425.9546.145.camel@localhost>
	<4B78F7FC.3060600@businessecurity.com>
Message-ID: <20100215101156.GS6083@trillke.net>

On Mon, Feb 15, 2010 at 08:30 +0100, Pontus ?str?m wrote:
> Ronny Pfannschmidt wrote:
> > On Fri, 2010-02-12 at 22:23 +0100, holger krekel wrote:
> >   
> > I have some basic ideas about structuring that kind of test.
> >
> > A) steped reporting, so each test reports the current step
> > B) collection of dependend test-items, having each test item as `step`
> >
> > A requires extending the py.test reporting (but might be easy)
> > B requires extending the py.test test execution
> >   
> Could you just elaborate a bit on the above items and giving the 
> rationale for each approach. I currently have some difficulty 
> understanding what you mean.

Regarding approach B i recommend to check out the fine docs  
that Ronny pointed to, in this file: 

http://bitbucket.org/aafshar/glashammer-testing/src/tip/glashammer/utils/testing
.py 

Regarding approach A: currently test items are collected and executed 
and reported.  They are the basic unit of testing and they are meant to 
be independent and isolated from each other although they may share and 
often do share fixture code.  

Domain-specific acceptance testing tests may run longer
and they may involve "logical" steps that need to happen in a certain order.
Mapping those steps to test items conflicts with the isolation above. 
One idea is to simply flexibilize reporting and signal "step" 
results to the terminal (or other) reporters.  And otherwize keep
the isolation.  This is approach A. 

B works now, and i'd help to make A work if there are concrete use
cases and no better solution. 

HTH,
holger

From holger at merlinux.eu  Mon Feb 15 11:20:19 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 15 Feb 2010 11:20:19 +0100
Subject: [py-dev] Testing daemonize() (of sorts)
In-Reply-To: <e1a84d571002140648l52a6713fjfc542a05a28cd34f@mail.gmail.com>
References: <e1a84d571002140648l52a6713fjfc542a05a28cd34f@mail.gmail.com>
Message-ID: <20100215102019.GT6083@trillke.net>

Hi James,

On Mon, Feb 15, 2010 at 00:48 +1000, James Mills wrote:
> Hi Folks,
> 
> Not sure how big this community here is, but at

There are around 130 people subscribed here but i don't know
how many are how deep into things :) 

> the suggestion of Ronny, here's a problem I'd like
> to "throw" at you:
> 
> Consider the following test for my library circuits (1):
> 
> http://bitbucket.org/prologic/circuits-dev/src/tip/tests/app/test_daemon.py
> 
> Notice how I have to externally call "python app.py <pidfile>" in order to
> make the test work ? I haven't found a way to integrate the app within the
> test function/module at all without errors flying widely.

sidenote: i think you could make good use of the "tmpdir" funcarg here to avoid
writing ".pid" files to random places.  See  "py.test --funcargs" for info.

> The problem with the above method (although works and passes) is that
> the no coverage data is picked up by the fact that "app.py" was executed
> and therefore parts (or all) of the Daemon Component (2) were actually
> covered.
> 
> Anyone have any suggestions or workarounds here ?

IMO this needs looking 

a) into how to merge coverage data and report it from multiple sources
   (probably pytest-coverage which you are working on could be tweaked) 
b) how to write a nice funcarg that helps running a python script with 
   coverage configured accordingly.   That funcarg should maybe live
   with that plugin. 

HTH,
holger

From Ronny.Pfannschmidt at gmx.de  Mon Feb 15 11:38:50 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Mon, 15 Feb 2010 11:38:50 +0100
Subject: [py-dev] the seeming need of task-based build-tool properties in
	py.test
Message-ID: <1266230330.18644.4.camel@localhost>

hi,

as needs like dependend tests, checking the need for test execution and
the changes in distribution emerge,
it seems like we are going tinto the direction of a task-based build
tool where each test item is a 'task' that may depend on other tasks and
has possible checked preconditions for being executed.


i just wanted to throw that at the ml so people can discuss.


-- Ronny


From holger at merlinux.eu  Mon Feb 15 12:01:28 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 15 Feb 2010 12:01:28 +0100
Subject: [py-dev] the seeming need of task-based build-tool
	properties	in py.test
In-Reply-To: <1266230330.18644.4.camel@localhost>
References: <1266230330.18644.4.camel@localhost>
Message-ID: <20100215110128.GV6083@trillke.net>

Hey Ronny, 

On Mon, Feb 15, 2010 at 11:38 +0100, Ronny Pfannschmidt wrote:
> as needs like dependend tests, checking the need for test execution and
> the changes in distribution emerge,

for everybodies information, this is partly a reference to IRC discussions. 

> it seems like we are going tinto the direction of a task-based build
> tool where each test item is a 'task' that may depend on other tasks and
> has possible checked preconditions for being executed.

not sure i agree.  I'd like to keep the base functionality and py.test tool
simple and rather work on higher level goals in separate projects
and also include support for nose and unittests there. 

There are various build approaches ('doit' is one interesting one
recently mentioned here) and i'd like to leverage those. 

That being said, I see overlap on testing and deployment. 
Those who were at Pycon 2009 and EuroPython know that i regard it
as natural to have (functional) testing and deployment of software 
converge in the future.  After all deployment is a kind of a test 
usually involving humans interacting with the software.  And the work done
to prepare functional tests involves automatically installing software.  
It makes sense to me to re-use the same techniques (e.g. virtualenv, 
distutils installs, build-tools etc.) for preparing automated test 
runs and for deploying code. 

> i just wanted to throw that at the ml so people can discuss.

heh, please try to not post too many mails about details or
ideas here, though.  After all it's more the execution of ideas 
which counts rather than dropping them :) 

cheers & all the best,
holger

From Adam.Schmalhofer at gmx.de  Mon Feb 15 14:50:31 2010
From: Adam.Schmalhofer at gmx.de (Adam)
Date: Mon, 15 Feb 2010 14:50:31 +0100
Subject: [py-dev] the seeming need of task-based build-tool properties
 in py.test
In-Reply-To: <1266230330.18644.4.camel@localhost>
References: <1266230330.18644.4.camel@localhost>
Message-ID: <20100215145031.3adddf26@deepthought>

Ronny Pfannschmidt wrote:

> as needs like dependend tests, [...]
> it seems like we are going tinto the direction of a task-based build
> tool where each test item is a 'task' that may depend on other tasks and
> has possible checked preconditions for being executed.

A test dependency is IMO very different to a build dependency. With a
build dependency the task can't be run until it's dependency have
produced their product. If they are run in a wrong order, it produces a
broken build.

OTOH the test dependencies are only relevant for interpreting why a test
failed. If (at least) one dependency failed, I don't care if the test
passt or not. In which order the two were run is irrelevant. Sure, if I
ran the dependency first, I can save time, but as (with the exception of
looponfailing) '#failed test << #tests' it shouldn't make much of a
difference).

--Adam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20100215/d63a45e5/attachment.pgp 

From Ronny.Pfannschmidt at gmx.de  Wed Feb 17 15:41:43 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Wed, 17 Feb 2010 15:41:43 +0100
Subject: [py-dev] the seeming need of task-based build-tool properties
 in py.test
In-Reply-To: <20100215145031.3adddf26@deepthought>
References: <1266230330.18644.4.camel@localhost>
	<20100215145031.3adddf26@deepthought>
Message-ID: <1266417703.16084.20.camel@localhost>

On Mon, 2010-02-15 at 14:50 +0100, Adam wrote:
> Ronny Pfannschmidt wrote:
> 
> > as needs like dependend tests, [...]
> > it seems like we are going tinto the direction of a task-based build
> > tool where each test item is a 'task' that may depend on other tasks and
> > has possible checked preconditions for being executed.
> 
> A test dependency is IMO very different to a build dependency. With a
> build dependency the task can't be run until it's dependency have
> produced their product. If they are run in a wrong order, it produces a
> broken build.

ordering issues indeed get important as soon as one creates test-items
that depend on the order and execution of other test items

this is already happening for glashammers acceptance-testsuite
another part of the issue is tests that take long,
but are not required to run every time - like for example code
validators

-- Ronny

> 
> OTOH the test dependencies are only relevant for interpreting why a test
> failed. If (at least) one dependency failed, I don't care if the test
> passt or not. In which order the two were run is irrelevant. Sure, if I
> ran the dependency first, I can save time, but as (with the exception of
> looponfailing) '#failed test << #tests' it shouldn't make much of a
> difference).
> 
> --Adam


From Adam.Schmalhofer at gmx.de  Wed Feb 17 17:13:01 2010
From: Adam.Schmalhofer at gmx.de (Adam)
Date: Wed, 17 Feb 2010 17:13:01 +0100
Subject: [py-dev] the seeming need of task-based build-tool properties
 in py.test
In-Reply-To: <1266417703.16084.20.camel@localhost>
References: <1266230330.18644.4.camel@localhost>
	<20100215145031.3adddf26@deepthought>
	<1266417703.16084.20.camel@localhost>
Message-ID: <20100217171301.3f9bd618@deepthought>

Ronny Pfannschmidt wrote:

> ordering issues indeed get important as soon as one creates test-items
> that depend on the order and execution of other test items
> 
> this is already happening for glashammers acceptance-testsuite

Personally, I consider this a broken test setup that really should be
separated between a cached_setup and the tests. I wouldn't want to leave
a global state around. However, I don't know hard this is for
glashammers specific cases. And I guess it is a sort of boilerplate.

> another part of the issue is tests that take long,
> but are not required to run every time - like for example code
> validators

I consider this a separate issue (and would be cool to have).

--Adam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20100217/a3549318/attachment.pgp 

From Ronny.Pfannschmidt at gmx.de  Wed Feb 17 17:43:05 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Wed, 17 Feb 2010 17:43:05 +0100
Subject: [py-dev] the seeming need of task-based build-tool properties
 in py.test
In-Reply-To: <20100217171301.3f9bd618@deepthought>
References: <1266230330.18644.4.camel@localhost>
	<20100215145031.3adddf26@deepthought>
	<1266417703.16084.20.camel@localhost>
	<20100217171301.3f9bd618@deepthought>
Message-ID: <1266424985.16084.27.camel@localhost>

On Wed, 2010-02-17 at 17:13 +0100, Adam wrote:
> Ronny Pfannschmidt wrote:
> 
> > ordering issues indeed get important as soon as one creates test-items
> > that depend on the order and execution of other test items
> > 
> > this is already happening for glashammers acceptance-testsuite
> 
its more or less breaking a big far acceptance test down in reportable
steps

the current solution isnt nice, but works in the current py.test,
it will have to be adapted once we have a full decission on how to
handle steps of acceptance tests (the ideas are still fuzzy)

> Personally, I consider this a broken test setup that really should be
> separated between a cached_setup and the tests. I wouldn't want to leave
> a global state around. However, I don't know hard this is for
> glashammers specific cases. And I guess it is a sort of boilerplate.
> 
one of the inherent properties of those acceptance tests is,
that a step in the middle ma fail without necessaryly breaking the rest,
however the order is important

the same would go for doctest chunks

order dependce, failure indepence

its generally a tricky area to deal with and i expect that we do it
wrong a few times before something thats really acceptable emerges as
the result of feedback

-- Ronny


> > another part of the issue is tests that take long,
> > but are not required to run every time - like for example code
> > validators
> 
> I consider this a separate issue (and would be cool to have).
> 
> --Adam


From wam at cisco.com  Tue Mar  2 17:46:20 2010
From: wam at cisco.com (William McVey)
Date: Tue, 02 Mar 2010 11:46:20 -0500
Subject: [py-dev] py.path.local no longer iterable?
Message-ID: <1267548380.3539.486.camel@talyn.cisco.com>

So, I've been running py-1.0.2 for quite a while. I'm now trying to
upgrade my code to use the current py library (1.2.1) and standalone
execnet. I'm curious whether the removal of the iterator functionality
on os.path.local() objects was intentional. I read through the
changelog, and didn't see anything other than:

1.0.2 -> 1.1.0
* simplified internal localpath implementation

To me though, I would have expected the API to stay consistent though.

  -- William

P.S. Perhaps I missed it, but Py lib's website doesn't seem to give a
link to a public code repository for the Py lib. I eventually found it
(I think) under Holger's bitbucket account.


From Adam.Schmalhofer at gmx.de  Wed Mar  3 18:27:46 2010
From: Adam.Schmalhofer at gmx.de (Adam)
Date: Wed, 3 Mar 2010 18:27:46 +0100
Subject: [py-dev] py.path.local no longer iterable?
In-Reply-To: <1267548380.3539.486.camel@talyn.cisco.com>
References: <1267548380.3539.486.camel@talyn.cisco.com>
Message-ID: <20100303182746.7476b638@deepthought>

William McVey wrote:

> So, I've been running py-1.0.2 for quite a while. I'm now trying to
> upgrade my code to use the current py library (1.2.1) and standalone
> execnet. I'm curious whether the removal of the iterator functionality
> on os.path.local() objects was intentional. I read through the
> changelog, and didn't see anything other than:
> 
> 1.0.2 -> 1.1.0
> * simplified internal localpath implementation
> 
> To me though, I would have expected the API to stay consistent though.

Use py.path.local('~').visit() it works in both Versions. Can't tell you
if the removal was intentional or not.

--Adam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20100303/0041e3e9/attachment.pgp 

From holger at merlinux.eu  Thu Mar  4 21:03:39 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 4 Mar 2010 21:03:39 +0100
Subject: [py-dev] py.path.local no longer iterable?
In-Reply-To: <1267548380.3539.486.camel@talyn.cisco.com>
References: <1267548380.3539.486.camel@talyn.cisco.com>
Message-ID: <20100304200339.GL3492@trillke.net>

On Tue, Mar 02, 2010 at 11:46 -0500, William McVey wrote:
> So, I've been running py-1.0.2 for quite a while. I'm now trying to
> upgrade my code to use the current py library (1.2.1) and standalone
> execnet. I'm curious whether the removal of the iterator functionality
> on os.path.local() objects was intentional. I read through the
> changelog, and didn't see anything other than:
> 
> 1.0.2 -> 1.1.0
> * simplified internal localpath implementation

not very detailed, sorry. 
iterator got removed because there should be only one way to do it
and "listdir()" does what the iterator does already. 

> To me though, I would have expected the API to stay consistent though.

In retrospect it's maybe questionable to remove the iterator (and the
__contains__ method).  To be honest i am never quite sure how many 
people depend on py.path as opposed to py.test.  

>   -- William
> 
> P.S. Perhaps I missed it, but Py lib's website doesn't seem to give a
> link to a public code repository for the Py lib. I eventually found it
> (I think) under Holger's bitbucket account.

I think that 

    http://codespeak.net/py/dist/install.html

has several pointers to the hg repository or did you look
at other docs? 

cheers,
holger

From Ronny.Pfannschmidt at gmx.de  Mon Mar  8 15:59:10 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Mon, 08 Mar 2010 15:59:10 +0100
Subject: [py-dev] py.path.local no longer iterable?
In-Reply-To: <20100304200339.GL3492@trillke.net>
References: <1267548380.3539.486.camel@talyn.cisco.com>
	<20100304200339.GL3492@trillke.net>
Message-ID: <1268060350.23770.7.camel@localhost>

Hi,

Since i also started to depend on py.path,
i started to think about making it a standalone library.

Since this would also help me to make py.path a more suitable base for
anyvc, as well as a good runtime dependency for kij and pida i'm
obviously in favor.

How do others think about such a change?

Regards, Ronny

On Thu, 2010-03-04 at 21:03 +0100, holger krekel wrote:
> On Tue, Mar 02, 2010 at 11:46 -0500, William McVey wrote:
> > So, I've been running py-1.0.2 for quite a while. I'm now trying to
> > upgrade my code to use the current py library (1.2.1) and standalone
> > execnet. I'm curious whether the removal of the iterator functionality
> > on os.path.local() objects was intentional. I read through the
> > changelog, and didn't see anything other than:
> > 
> > 1.0.2 -> 1.1.0
> > * simplified internal localpath implementation
> 
> not very detailed, sorry. 
> iterator got removed because there should be only one way to do it
> and "listdir()" does what the iterator does already. 
> 
> > To me though, I would have expected the API to stay consistent though.
> 
> In retrospect it's maybe questionable to remove the iterator (and the
> __contains__ method).  To be honest i am never quite sure how many 
> people depend on py.path as opposed to py.test.  
> 
> >   -- William
> > 
> > P.S. Perhaps I missed it, but Py lib's website doesn't seem to give a
> > link to a public code repository for the Py lib. I eventually found it
> > (I think) under Holger's bitbucket account.
> 
> I think that 
> 
>     http://codespeak.net/py/dist/install.html
> 
> has several pointers to the hg repository or did you look
> at other docs? 
> 
> cheers,
> holger