From holger at merlinux.eu Tue Aug 4 12:08:39 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 4 Aug 2009 12:08:39 +0200 Subject: [py-dev] pylib-1.0.0 released ... Message-ID: <20090804100839.GP31589@trillke.net> Hi folks, thanks to you all i've just released a py.test 1.0.0 final. actually i ran out of Beta numbers and thought i should probably rather go for a 1.0.1 if it comes to it :) anyway, hope everything is well ... see also the blog post: http://tetamap.wordpress.com/2009/08/04/pylib-1-0-0 let me know of any problems or - even better - success stories :) cheers & best, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From pedronis at openend.se Tue Aug 4 18:38:15 2009 From: pedronis at openend.se (Samuele Pedroni) Date: Tue, 04 Aug 2009 18:38:15 +0200 Subject: [py-dev] oejskit javascript testing 0.8.6 released Re: pylib-1.0.0 released ... In-Reply-To: <20090804100839.GP31589@trillke.net> References: <20090804100839.GP31589@trillke.net> Message-ID: <4A7863F7.4010704@openend.se> holger krekel wrote: > Hi folks, > > thanks to you all i've just released a py.test 1.0.0 final. > actually i ran out of Beta numbers and thought i should > probably rather go for a 1.0.1 if it comes to it :) > > anyway, hope everything is well ... see also the blog post: > > http://tetamap.wordpress.com/2009/08/04/pylib-1-0-0 > > let me know of any problems or - even better - success stories :) > there were some last minute compatibility issues between oejskit and py.test 1.0 final, hpk provided some patches to fix them (thanks) I have now pushed a 0.8.6 release including them to PyPI, see also the changelog: http://pypi.python.org/pypi/oejskit Samuele Pedroni for Open End From py-dev at tolomea.com Fri Aug 7 10:53:58 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Fri, 7 Aug 2009 18:53:58 +1000 Subject: [py-dev] issues with stdout redirection, ctypes and py.test Message-ID: My python code talks to a C library via ctypes and it in turn prints debug to stdout. And we test this with py.test, which by itself works just fine. But if at the bash prompt we then redirect the output of py.test to a file suddenly the C debug starts propagating out of py.test. We generally run py.test with -v and -x, but removing those didn't change the behavior at all. I'm at a bit of loss as to where to begin with this one, any suggestions? gordonw at gohma:~$ uname -a Linux gohma 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC 2009 i686 GNU/Linux gordonw at gohma:~$ python Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import py >>> py.version '1.0.0' Regards, Gordon From holger at merlinux.eu Fri Aug 7 12:02:51 2009 From: holger at merlinux.eu (holger krekel) Date: Fri, 7 Aug 2009 12:02:51 +0200 Subject: [py-dev] issues with stdout redirection, ctypes and py.test In-Reply-To: References: Message-ID: <20090807100250.GD31589@trillke.net> Hi Gordon, On Fri, Aug 07, 2009 at 18:53 +1000, Gordon Wrigley wrote: > My python code talks to a C library via ctypes and it in turn prints > debug to stdout. > And we test this with py.test, which by itself works just fine. by this you mean that it looks roughly like this: http://paste.pocoo.org/show/132982/ right? > But if at the bash prompt we then redirect the output of py.test to a > file suddenly the C debug starts propagating out of py.test. hum, redirecting the above example with "py.test x.py >log" works fine. The following may be interesting to observe (i just did): def test_hello(): myfile = os.fdopen(1, "w") myfile.write("hello\n") myfile.flush() assert 0 This works fine but if i leave out the flush() the write will *not* be captured appropriately. I guess that it is because of the missing buffering ("os.fdopen(1, 'w', 1)" and no flush works) FYI the pytest_capture plugin resumes capturing for calling into test methods, setup/teardown code and collection respectively and otherwise suspends capturing. Even if this was modified (i.e. capturing would always happen) i imagine that the missing flush/close could associate the actual write into a different test. Maybe your behaviour is still a different issue or even a bug, though. > We generally run py.test with -v and -x, but removing those didn't > change the behavior at all. that shouldn't change anything related to capturing, indeed. > I'm at a bit of loss as to where to begin with this one, any suggestions? maybe my above considerations help a bit and you can maybe come up with a breaking example or fix things on your side? I want to do a 1.0.1 soon with some capturing fixes (related to unicode handling, though) and i'd like to include any other related improvements or add to the docs. best, holger > gordonw at gohma:~$ uname -a > Linux gohma 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC > 2009 i686 GNU/Linux > gordonw at gohma:~$ python > Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) > [GCC 4.3.3] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import py > >>> py.version > '1.0.0' > > Regards, > Gordon > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From py-dev at tolomea.com Fri Aug 7 12:31:45 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Fri, 7 Aug 2009 20:31:45 +1000 Subject: [py-dev] issues with stdout redirection, ctypes and py.test In-Reply-To: <20090807100250.GD31589@trillke.net> References: <20090807100250.GD31589@trillke.net> Message-ID: I need to have a think about what you've said and look at producing a minimal reproduction. However I did forget to mention that the prints from the python code are fine, it's only the ones from C that are affected, in the good case the two sets are interleaved in the py.test capture, in the bad case the python prints are in the py.test capture and the C prints come out of py.test's stdout. Now that I think about it some more I'm inclined to wonder from where (and when) the C library acquires it's stdout handle. On Fri, Aug 7, 2009 at 8:02 PM, holger krekel wrote: > Hi Gordon, > > On Fri, Aug 07, 2009 at 18:53 +1000, Gordon Wrigley wrote: >> My python code talks to a C library via ctypes and it in turn prints >> debug to stdout. >> And we test this with py.test, which by itself works just fine. > > by this you mean that it looks roughly like this: > > ? ?http://paste.pocoo.org/show/132982/ > > right? > >> But if at the bash prompt we then redirect the output of py.test to a >> file suddenly the C debug starts propagating out of py.test. > > hum, redirecting the above example with "py.test x.py >log" works fine. > > The following may be interesting to observe (i just did): > > ? ?def test_hello(): > ? ? ? ?myfile = os.fdopen(1, "w") > ? ? ? ?myfile.write("hello\n") > ? ? ? ?myfile.flush() > ? ? ? ?assert 0 > > This works fine but if i leave out the flush() the write > will *not* be captured appropriately. ?I guess that it is because > of the missing buffering ("os.fdopen(1, 'w', 1)" and no flush works) > > FYI the pytest_capture plugin resumes capturing for calling > into test methods, setup/teardown code and collection > respectively and otherwise suspends capturing. ?Even if this > was modified (i.e. capturing would always happen) i imagine > that the missing flush/close could associate the actual write > into a different test. > > Maybe your behaviour is still a different issue or even a bug, though. > >> We generally run py.test with -v and -x, but removing those didn't >> change the behavior at all. > > that shouldn't change anything related to capturing, indeed. > >> I'm at a bit of loss as to where to begin with this one, any suggestions? > > maybe my above considerations help a bit and you can maybe > come up with a breaking example or fix things on your side? > > I want to do a 1.0.1 soon with some capturing fixes (related > to unicode handling, though) and i'd like to include any other > related improvements or add to the docs. > > best, > holger > >> gordonw at gohma:~$ uname -a >> Linux gohma 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC >> 2009 i686 GNU/Linux >> gordonw at gohma:~$ python >> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) >> [GCC 4.3.3] on linux2 >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import py >> >>> py.version >> '1.0.0' >> >> Regards, >> Gordon >> _______________________________________________ >> py-dev mailing list >> py-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/py-dev >> > > -- > Metaprogramming, Python, Testing: http://tetamap.wordpress.com > Python, PyPy, pytest contracting: http://merlinux.eu > From py-dev at tolomea.com Sat Aug 8 06:43:24 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Sat, 8 Aug 2009 14:43:24 +1000 Subject: [py-dev] issues with stdout redirection, ctypes and py.test In-Reply-To: References: <20090807100250.GD31589@trillke.net> Message-ID: Since I have no clear concept of what is supposed to happen when a C function called via ctypes does a printf, I have instead gone through the C library and arranged to have all the printing routed through a function pointer which I now setup as a python callback that does a sys.stdout.write(). Problem solved. On Fri, Aug 7, 2009 at 8:31 PM, Gordon Wrigley wrote: > I need to have a think about what you've said and look at producing a > minimal reproduction. However I did forget to mention that the prints > from the python code are fine, it's only the ones from C that are > affected, in the good case the two sets are interleaved in the py.test > capture, in the bad case the python prints are in the py.test capture > and the C prints come out of py.test's stdout. > Now that I think about it some more I'm inclined to wonder from where > (and when) the C library acquires it's stdout handle. > > On Fri, Aug 7, 2009 at 8:02 PM, holger krekel wrote: >> Hi Gordon, >> >> On Fri, Aug 07, 2009 at 18:53 +1000, Gordon Wrigley wrote: >>> My python code talks to a C library via ctypes and it in turn prints >>> debug to stdout. >>> And we test this with py.test, which by itself works just fine. >> >> by this you mean that it looks roughly like this: >> >> ? ?http://paste.pocoo.org/show/132982/ >> >> right? >> >>> But if at the bash prompt we then redirect the output of py.test to a >>> file suddenly the C debug starts propagating out of py.test. >> >> hum, redirecting the above example with "py.test x.py >log" works fine. >> >> The following may be interesting to observe (i just did): >> >> ? ?def test_hello(): >> ? ? ? ?myfile = os.fdopen(1, "w") >> ? ? ? ?myfile.write("hello\n") >> ? ? ? ?myfile.flush() >> ? ? ? ?assert 0 >> >> This works fine but if i leave out the flush() the write >> will *not* be captured appropriately. ?I guess that it is because >> of the missing buffering ("os.fdopen(1, 'w', 1)" and no flush works) >> >> FYI the pytest_capture plugin resumes capturing for calling >> into test methods, setup/teardown code and collection >> respectively and otherwise suspends capturing. ?Even if this >> was modified (i.e. capturing would always happen) i imagine >> that the missing flush/close could associate the actual write >> into a different test. >> >> Maybe your behaviour is still a different issue or even a bug, though. >> >>> We generally run py.test with -v and -x, but removing those didn't >>> change the behavior at all. >> >> that shouldn't change anything related to capturing, indeed. >> >>> I'm at a bit of loss as to where to begin with this one, any suggestions? >> >> maybe my above considerations help a bit and you can maybe >> come up with a breaking example or fix things on your side? >> >> I want to do a 1.0.1 soon with some capturing fixes (related >> to unicode handling, though) and i'd like to include any other >> related improvements or add to the docs. >> >> best, >> holger >> >>> gordonw at gohma:~$ uname -a >>> Linux gohma 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC >>> 2009 i686 GNU/Linux >>> gordonw at gohma:~$ python >>> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) >>> [GCC 4.3.3] on linux2 >>> Type "help", "copyright", "credits" or "license" for more information. >>> >>> import py >>> >>> py.version >>> '1.0.0' >>> >>> Regards, >>> Gordon >>> _______________________________________________ >>> py-dev mailing list >>> py-dev at codespeak.net >>> http://codespeak.net/mailman/listinfo/py-dev >>> >> >> -- >> Metaprogramming, Python, Testing: http://tetamap.wordpress.com >> Python, PyPy, pytest contracting: http://merlinux.eu >> > From holger at merlinux.eu Sat Aug 8 16:24:04 2009 From: holger at merlinux.eu (holger krekel) Date: Sat, 8 Aug 2009 16:24:04 +0200 Subject: [py-dev] issues with stdout redirection, ctypes and py.test In-Reply-To: References: <20090807100250.GD31589@trillke.net> Message-ID: <20090808142404.GH31589@trillke.net> On Sat, Aug 08, 2009 at 14:43 +1000, Gordon Wrigley wrote: > Since I have no clear concept of what is supposed to happen when a C > function called via ctypes does a printf, I have instead gone through > the C library and arranged to have all the printing routed through a > function pointer which I now setup as a python callback that does a > sys.stdout.write(). Problem solved. if you can try to ensure open the file (look for "fdopen(2)" or so) in unbuffered mode that should work. Would be good to know. I have played on the command line and it appeared to me that this buffering mode is very likely the culprit. cheers, holger > On Fri, Aug 7, 2009 at 8:31 PM, Gordon Wrigley wrote: > > I need to have a think about what you've said and look at producing a > > minimal reproduction. However I did forget to mention that the prints > > from the python code are fine, it's only the ones from C that are > > affected, in the good case the two sets are interleaved in the py.test > > capture, in the bad case the python prints are in the py.test capture > > and the C prints come out of py.test's stdout. > > Now that I think about it some more I'm inclined to wonder from where > > (and when) the C library acquires it's stdout handle. > > > > On Fri, Aug 7, 2009 at 8:02 PM, holger krekel wrote: > >> Hi Gordon, > >> > >> On Fri, Aug 07, 2009 at 18:53 +1000, Gordon Wrigley wrote: > >>> My python code talks to a C library via ctypes and it in turn prints > >>> debug to stdout. > >>> And we test this with py.test, which by itself works just fine. > >> > >> by this you mean that it looks roughly like this: > >> > >> ? ?http://paste.pocoo.org/show/132982/ > >> > >> right? > >> > >>> But if at the bash prompt we then redirect the output of py.test to a > >>> file suddenly the C debug starts propagating out of py.test. > >> > >> hum, redirecting the above example with "py.test x.py >log" works fine. > >> > >> The following may be interesting to observe (i just did): > >> > >> ? ?def test_hello(): > >> ? ? ? ?myfile = os.fdopen(1, "w") > >> ? ? ? ?myfile.write("hello\n") > >> ? ? ? ?myfile.flush() > >> ? ? ? ?assert 0 > >> > >> This works fine but if i leave out the flush() the write > >> will *not* be captured appropriately. ?I guess that it is because > >> of the missing buffering ("os.fdopen(1, 'w', 1)" and no flush works) > >> > >> FYI the pytest_capture plugin resumes capturing for calling > >> into test methods, setup/teardown code and collection > >> respectively and otherwise suspends capturing. ?Even if this > >> was modified (i.e. capturing would always happen) i imagine > >> that the missing flush/close could associate the actual write > >> into a different test. > >> > >> Maybe your behaviour is still a different issue or even a bug, though. > >> > >>> We generally run py.test with -v and -x, but removing those didn't > >>> change the behavior at all. > >> > >> that shouldn't change anything related to capturing, indeed. > >> > >>> I'm at a bit of loss as to where to begin with this one, any suggestions? > >> > >> maybe my above considerations help a bit and you can maybe > >> come up with a breaking example or fix things on your side? > >> > >> I want to do a 1.0.1 soon with some capturing fixes (related > >> to unicode handling, though) and i'd like to include any other > >> related improvements or add to the docs. > >> > >> best, > >> holger > >> > >>> gordonw at gohma:~$ uname -a > >>> Linux gohma 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC > >>> 2009 i686 GNU/Linux > >>> gordonw at gohma:~$ python > >>> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) > >>> [GCC 4.3.3] on linux2 > >>> Type "help", "copyright", "credits" or "license" for more information. > >>> >>> import py > >>> >>> py.version > >>> '1.0.0' > >>> > >>> Regards, > >>> Gordon > >>> _______________________________________________ > >>> py-dev mailing list > >>> py-dev at codespeak.net > >>> http://codespeak.net/mailman/listinfo/py-dev > >>> > >> > >> -- > >> Metaprogramming, Python, Testing: http://tetamap.wordpress.com > >> Python, PyPy, pytest contracting: http://merlinux.eu > >> > > > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From holger at merlinux.eu Sat Aug 8 16:50:18 2009 From: holger at merlinux.eu (holger krekel) Date: Sat, 8 Aug 2009 16:50:18 +0200 Subject: [py-dev] issues with stdout redirection, ctypes and py.test In-Reply-To: <20090808142404.GH31589@trillke.net> References: <20090807100250.GD31589@trillke.net> <20090808142404.GH31589@trillke.net> Message-ID: <20090808145018.GJ31589@trillke.net> On Sat, Aug 08, 2009 at 16:24 +0200, holger krekel wrote: > On Sat, Aug 08, 2009 at 14:43 +1000, Gordon Wrigley wrote: > > Since I have no clear concept of what is supposed to happen when a C > > function called via ctypes does a printf, I have instead gone through > > the C library and arranged to have all the printing routed through a > > function pointer which I now setup as a python callback that does a > > sys.stdout.write(). Problem solved. > > if you can try to ensure open the file (look for "fdopen(2)" or so) probably not the right suggestion - i didn't do C for a long time - but fsync(1) after each printf (maybe done in a macro anyway?) could show if it's a buffering issue. best, holger > in unbuffered mode that should work. Would be good to know. > I have played on the command line and it appeared to me that > this buffering mode is very likely the culprit. > > cheers, > holger > > > > On Fri, Aug 7, 2009 at 8:31 PM, Gordon Wrigley wrote: > > > I need to have a think about what you've said and look at producing a > > > minimal reproduction. However I did forget to mention that the prints > > > from the python code are fine, it's only the ones from C that are > > > affected, in the good case the two sets are interleaved in the py.test > > > capture, in the bad case the python prints are in the py.test capture > > > and the C prints come out of py.test's stdout. > > > Now that I think about it some more I'm inclined to wonder from where > > > (and when) the C library acquires it's stdout handle. > > > > > > On Fri, Aug 7, 2009 at 8:02 PM, holger krekel wrote: > > >> Hi Gordon, > > >> > > >> On Fri, Aug 07, 2009 at 18:53 +1000, Gordon Wrigley wrote: > > >>> My python code talks to a C library via ctypes and it in turn prints > > >>> debug to stdout. > > >>> And we test this with py.test, which by itself works just fine. > > >> > > >> by this you mean that it looks roughly like this: > > >> > > >> ? ?http://paste.pocoo.org/show/132982/ > > >> > > >> right? > > >> > > >>> But if at the bash prompt we then redirect the output of py.test to a > > >>> file suddenly the C debug starts propagating out of py.test. > > >> > > >> hum, redirecting the above example with "py.test x.py >log" works fine. > > >> > > >> The following may be interesting to observe (i just did): > > >> > > >> ? ?def test_hello(): > > >> ? ? ? ?myfile = os.fdopen(1, "w") > > >> ? ? ? ?myfile.write("hello\n") > > >> ? ? ? ?myfile.flush() > > >> ? ? ? ?assert 0 > > >> > > >> This works fine but if i leave out the flush() the write > > >> will *not* be captured appropriately. ?I guess that it is because > > >> of the missing buffering ("os.fdopen(1, 'w', 1)" and no flush works) > > >> > > >> FYI the pytest_capture plugin resumes capturing for calling > > >> into test methods, setup/teardown code and collection > > >> respectively and otherwise suspends capturing. ?Even if this > > >> was modified (i.e. capturing would always happen) i imagine > > >> that the missing flush/close could associate the actual write > > >> into a different test. > > >> > > >> Maybe your behaviour is still a different issue or even a bug, though. > > >> > > >>> We generally run py.test with -v and -x, but removing those didn't > > >>> change the behavior at all. > > >> > > >> that shouldn't change anything related to capturing, indeed. > > >> > > >>> I'm at a bit of loss as to where to begin with this one, any suggestions? > > >> > > >> maybe my above considerations help a bit and you can maybe > > >> come up with a breaking example or fix things on your side? > > >> > > >> I want to do a 1.0.1 soon with some capturing fixes (related > > >> to unicode handling, though) and i'd like to include any other > > >> related improvements or add to the docs. > > >> > > >> best, > > >> holger > > >> > > >>> gordonw at gohma:~$ uname -a > > >>> Linux gohma 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC > > >>> 2009 i686 GNU/Linux > > >>> gordonw at gohma:~$ python > > >>> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) > > >>> [GCC 4.3.3] on linux2 > > >>> Type "help", "copyright", "credits" or "license" for more information. > > >>> >>> import py > > >>> >>> py.version > > >>> '1.0.0' > > >>> > > >>> Regards, > > >>> Gordon > > >>> _______________________________________________ > > >>> py-dev mailing list > > >>> py-dev at codespeak.net > > >>> http://codespeak.net/mailman/listinfo/py-dev > > >>> > > >> > > >> -- > > >> Metaprogramming, Python, Testing: http://tetamap.wordpress.com > > >> Python, PyPy, pytest contracting: http://merlinux.eu > > >> > > > > > > > -- > Metaprogramming, Python, Testing: http://tetamap.wordpress.com > Python, PyPy, pytest contracting: http://merlinux.eu > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From holger at merlinux.eu Wed Aug 12 20:33:42 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 12 Aug 2009 20:33:42 +0200 Subject: [py-dev] specifying testfile patterns / RFC Message-ID: <20090812183342.GT31589@trillke.net> Hi all, i am hacking on a new plugin to go into py.test-1.0.1 and i am doing that in documentation-driven style. So i am interested in feedback and comments on the below soon-to-become reality "pytest_testfiles" plugin. best & thanks, holger pytest_testfiles.py: determine test files for command line specified args. =========================================================================== usage example: specifying testfiles in a python module ----------------------------------------------------- If you have a module ``mymodule.py`` you can specify test files like this:: # content of: mymodule.py # relative paths __testfiles__ = ['test/test_unittest.py', 'test/test_functional.py'] and if you then type:: py.test mymodule.py then this will run the test files which were specified relatively to the directory of ``mymodule.py``. Ordering is significant: if you specify quick-running unit-tests first followed by slower running functional tests then issuing commands like ``py.test -x`` allows to find failures quickly and the easier-to-debug ones first. usage example: specifying project-specific testfile patterns -------------------------------------------------------------- Suppose your project has this layout:: app/ sub1/ module1.py tests/ unit/ test_module1.py functional/ test_one.py test_two.py you may specify filematching rules for finding tests like this:: # contents of: conftest.py conf_testfilepatterns = ["{topdir}/tests/unit/test_{basename}", "{topdir}/tests/functional/*.py"] and if you then type:: py.test app/sub1/module1.py the specified testfile patterns will be applied to check if there are matching test files. In our example we will run test files in the following order:: tests/unit/test_module.py tests/functional/test_one.py tests/functional/test_two.py default is to look for test files being close to code ---------------------------------------------------------- If no ``conf_testfilepatterns`` are specified, py.test will use this as a default setting:: conf_testfilepatterns = [ "*/test_{purebasename}.py", "**/test_*.py", "**/*_test.py" ] Note that each matching test file will only be run at most once. Substitutions ------------------- The following substitutions are performed for each file-or-directory command line argument:: dirname the dirname of the file basename basename of the file purebasename basename without the extension topdir first upwards parent directory not containing __init__.py From Ronny.Pfannschmidt at gmx.de Tue Aug 18 13:06:38 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Tue, 18 Aug 2009 13:06:38 +0200 Subject: [py-dev] building reusable testsuites Message-ID: <1250593598.23706.7.camel@localhost> Hi, while building the testsuite of anyvc i noticed i need a way to enable others to use my testsuite for backends on their own code in order to test/validate 3rd party backends. Right now i don't think its possible, please lets discuss possible solutions. Regards Ronny Pfannschmidt From holger at merlinux.eu Tue Aug 18 18:58:37 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 18 Aug 2009 18:58:37 +0200 Subject: [py-dev] building reusable testsuites In-Reply-To: <1250593598.23706.7.camel@localhost> References: <1250593598.23706.7.camel@localhost> Message-ID: <20090818165837.GA15455@trillke.net> Hey Ronny, On Tue, Aug 18, 2009 at 13:06 +0200, Ronny Pfannschmidt wrote: > while building the testsuite of anyvc > i noticed i need a way to enable others > to use my testsuite for backends on their own code > in order to test/validate 3rd party backends. > > Right now i don't think its possible, > please lets discuss possible solutions. given that this other person has a "mybackend.py" file maybe running: py.test mybackend.py could look at __testfiles__ in the module which would reference the tests you think each backend needs to pass? (see my recent RFC here on the list). The tests would require a function argument that could be setup by the mybackend.py file or within a conftest.py. best, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From holger at merlinux.eu Wed Aug 19 18:34:43 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 19 Aug 2009 18:34:43 +0200 Subject: [py-dev] 1.0.1 pylib/py.test: improved reporting, nose/unittest.py support, bug fixes Message-ID: <20090819163443.GE15455@trillke.net> Hi all, pylib/py.test 1.0.1 is a bugfix release also coming with: * improved documentation, site navigation, configuration help * test failure reporting improvements * support for directly running existing nose/unittest.py style tests visit here for more info, including quickstart and tutorials: http://pytest.org and http://pylib.org have fun, holger Changelog 1.0.0 to 1.0.1 ------------------------ * added a default 'pytest_nose' plugin which handles nose.SkipTest, nose-style function/method/generator setup/teardown and tries to report functions correctly. * improved documentation, better navigation: see http://pytest.org * added a "--help-config" option to show conftest.py / ENV-var names for all longopt cmdline options, and some special conftest.py variables. renamed 'conf_capture' conftest setting to 'option_capture' accordingly. * unicode fixes: capturing and unicode writes to sys.stdout (through e.g a print statement) now work within tests, they are encoded as "utf8" by default, also terminalwriting was adapted and somewhat unified between windows and linux * fix issue #27: better reporting on non-collectable items given on commandline (e.g. pyc files) * fix issue #33: added --version flag (thanks Benjamin Peterson) * fix issue #32: adding support for "incomplete" paths to wcpath.status() * "Test" prefixed classes are *not* collected by default anymore if they have an __init__ method * monkeypatch setenv() now accepts a "prepend" parameter * improved reporting of collection error tracebacks * simplified multicall mechanism and plugin architecture, renamed some internal methods and argnames From Ronny.Pfannschmidt at gmx.de Mon Aug 24 13:51:19 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Mon, 24 Aug 2009 13:51:19 +0200 Subject: [py-dev] outlining what i intend to do with execnet + what additional features could be helpfull Message-ID: <1251114679.32344.18.camel@localhost> hi, first let me outline my needs for anyvc a vcs abstraction lib pida a ide based on the idea that everything is a plugin anyvc ------ * execute backends in a different process * circumvent gpl/gpl2only of hg/dulwich/bzr * execute the fontend on python platforms not supported by the backends * python 3 * jython * ironpython * pypy pida ---- an ide based on plugins * run parts of plugins in different processes * avoid gil races for cpu-intensive tasks * run parts of plugins on different computers/platforms * test execution * introspectiong of test/deployment environments * general work on remote data/projects In order to archieve those goals i think i need a few conceptual ideas for installing the different libs on the different platforms as well as a tool to help proxying method calls to remote objects. regards Ronny From holger at merlinux.eu Mon Aug 24 14:34:14 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 24 Aug 2009 14:34:14 +0200 Subject: [py-dev] outlining what i intend to do with execnet + what additional features could be helpfull In-Reply-To: <1251114679.32344.18.camel@localhost> References: <1251114679.32344.18.camel@localhost> Message-ID: <20090824123414.GY15455@trillke.net> Hi Ronny, from IRC i also know that you are wondering how/if to best apply py.execnet for the tasks. Can you post an example of a frontend command/API you want to implement and some code of how that translates to one particular API? I'd then consider and suggest a way/method to apply execnet. cheers, holger On Mon, Aug 24, 2009 at 13:51 +0200, Ronny Pfannschmidt wrote: > hi, > > first let me outline my needs for > > anyvc > a vcs abstraction lib > pida > a ide based on the idea that everything is a plugin > > > anyvc > ------ > > * execute backends in a different process > * circumvent gpl/gpl2only of hg/dulwich/bzr > * execute the fontend on python platforms not supported by the backends > * python 3 > * jython > * ironpython > * pypy > > pida > ---- > > an ide based on plugins > > * run parts of plugins in different processes > * avoid gil races for cpu-intensive tasks > * run parts of plugins on different computers/platforms > * test execution > * introspectiong of test/deployment environments > * general work on remote data/projects > > > In order to archieve those goals > i think i need a few conceptual ideas > for installing the different libs on the different platforms > as well as a tool to help proxying method calls to remote objects. > > regards Ronny > > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From Ronny.Pfannschmidt at gmx.de Mon Aug 24 15:42:45 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Mon, 24 Aug 2009 15:42:45 +0200 Subject: [py-dev] outlining what i intend to do with execnet + what additional features could be helpfull In-Reply-To: <20090824123414.GY15455@trillke.net> References: <1251114679.32344.18.camel@localhost> <20090824123414.GY15455@trillke.net> Message-ID: <1251121365.32344.60.camel@localhost> On Mon, 2009-08-24 at 14:34 +0200, holger krekel wrote: > Hi Ronny, > > from IRC i also know that you are wondering how/if to best apply > py.execnet for the tasks. Can you post an example of > a frontend command/API you want to implement and some > code of how that translates to one particular API? > I'd then consider and suggest a way/method to apply execnet. i think a good initial example for anyvc would be one of the unittests def test_build_first_commit(mgr): repo = mgr.make_repo('repo') with repo.transaction(message='initial', author='test') as root: with root.join('test.txt').open('w') as f: f.write("text") with repo.get_default_head() as root: with root.join("test.txt").open() as f: content = f.read() assert content == 'text' this test creates a repo, an initial commit, then asserts the content mgr is a utility to manage the directories where tests dump their data make_repo creates the repository object that should "be" in another object when using py.execnet i'll try to extract something semilar for pida later > > cheers, > holger > > > On Mon, Aug 24, 2009 at 13:51 +0200, Ronny Pfannschmidt wrote: > > hi, > > > > first let me outline my needs for > > > > anyvc > > a vcs abstraction lib > > pida > > a ide based on the idea that everything is a plugin > > > > > > anyvc > > ------ > > > > * execute backends in a different process > > * circumvent gpl/gpl2only of hg/dulwich/bzr > > * execute the fontend on python platforms not supported by the backends > > * python 3 > > * jython > > * ironpython > > * pypy > > > > pida > > ---- > > > > an ide based on plugins > > > > * run parts of plugins in different processes > > * avoid gil races for cpu-intensive tasks > > * run parts of plugins on different computers/platforms > > * test execution > > * introspectiong of test/deployment environments > > * general work on remote data/projects > > > > > > In order to archieve those goals > > i think i need a few conceptual ideas > > for installing the different libs on the different platforms > > as well as a tool to help proxying method calls to remote objects. > > > > regards Ronny > > From holger at merlinux.eu Mon Aug 24 16:16:26 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 24 Aug 2009 16:16:26 +0200 Subject: [py-dev] outlining what i intend to do with execnet + what additional features could be helpfull In-Reply-To: <1251121365.32344.60.camel@localhost> References: <1251114679.32344.18.camel@localhost> <20090824123414.GY15455@trillke.net> <1251121365.32344.60.camel@localhost> Message-ID: <20090824141626.GB15455@trillke.net> On Mon, Aug 24, 2009 at 15:42 +0200, Ronny Pfannschmidt wrote: > On Mon, 2009-08-24 at 14:34 +0200, holger krekel wrote: > > Hi Ronny, > > > > from IRC i also know that you are wondering how/if to best apply > > py.execnet for the tasks. Can you post an example of > > a frontend command/API you want to implement and some > > code of how that translates to one particular API? > > I'd then consider and suggest a way/method to apply execnet. > > i think a good initial example for anyvc would be one of the unittests > > def test_build_first_commit(mgr): > repo = mgr.make_repo('repo') > with repo.transaction(message='initial', author='test') as root: > with root.join('test.txt').open('w') as f: > f.write("text") > > with repo.get_default_head() as root: > with root.join("test.txt").open() as f: > content = f.read() > assert content == 'text' > > this test creates a repo, an initial commit, then asserts the content > mgr is a utility to manage the directories where tests dump their data > make_repo creates the repository object that should "be" in another > object when using py.execnet The execnet spirit is to design your own local protocol. Let me give and give some context by means of an example: py/path/gateway contains an experimental remote-path implementation, using execnet: * remotepath.py: a "RemotePath" class (similar to your frontend "Repo" one) * channeltest.py: a PathServer backend implementing the fs access code Basically the frontend-class is connected through (sub) channels with a backend instance. If you say on the frontend: x = remotepath.join("hello") this will enter this code on the caller/client/frontend side: def join(self, *args): id = ~COUNTER.next() self._channel.send(('JOIN', self._id, id) + args) return RemotePath(self._channel, id) which creates a prospective 'id' for the result, sends a command to the backend and immediately returns. This has *zero* latency. If you later perform an operation on the returned instance like list() def listdir(self, *args): self._channel.send(('LIST', self._id) + args) return [RemotePath(self._channel, id, basename) for (id, basename) in self._channel.receive()] this will send a LIST command to the backend PathServer which itself implements it like this: def command_LIST(self, id, *args): path = self.C2P[id] answer = [(self.p2c(p), p.basename) for p in path.listdir(*args)] self.channel.send(answer) so here we create a local path using the client-provided ID and instantiate an answer. C2P and p2c() help to manage the ID/path relations. For implementing our own small custom "command" pattern protocol the backend PAthServer implements a simple dispatch loop based on the frontend/backend connecting channel: def serve(self): try: while 1: msg = self.channel.receive() meth = getattr(self, 'command_' + msg[0]) meth(*msg[1:]) except EOFError: pass hope this makes sense to you and serves as inspiration. To summarize: Design your own protocol, optimized for your special purposes. You can easily evolve your protocol on a per-need basis - no need to have global RPC or IDL/RMI interface definitions. There also is no need for "matching" server/client software etc. It's a zero-install "local" protocol, also easy to test. best, holger From Ronny.Pfannschmidt at gmx.de Thu Aug 27 10:02:06 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Thu, 27 Aug 2009 10:02:06 +0200 Subject: [py-dev] outlining some of my needs for execnet + possible solutions Message-ID: <1251360126.24112.59.camel@localhost> Hi, i'd like to outline some needs i have for execnet as well as propossing some rough sketchouts of possible solution py.execnet between python2 and python3 -------------------------------------- This arises as i want to use anyvc in python3 while the backends are not portable to python3 yet. However syntax differences make normal interaction hard and will most likely perfectly destroy the zero install mechanisms. installing more complex dependencies in virtualenvs and reusing those --------------------------------------------------------------------- Syntax differences between python versions as well as complex package dependencies mandate installing some packages on the remote side. Tools like virtualenv help with installing those separate from the normal system as well as with limited rights. However those tools might need some bootstraping outside of python as the remote might not be ready to just start up a execnet slave. a simple remote object protocol via wrappers around channels ------------------------------------------------------------ Inventing own protocols on top of channels if one want's to controll remote-objects is a fragile task, helper classes to ease the process are very welcome. the proposed solutions ----------------------- 1. gw.remote_call(remote_callable, *k, **kw) as alternative to gw.remote_exec(code) * import the callable remote_callable on the remote * call remote_callable(channel, *k, **kw) where channel is the usual remote_channel 2. a virtualenv based minimal install system it needs to do without a usable remote python (ie wrong platform, whatever): * create a virtualenv at a given path * install something like a minimal py.execnet slave, so the remote side can be started * all other install operations should be controllable via some kind of remote_exec/remote_call 3. RemoteCaller/RemoteHandler as wrappers around channels that represent remote objects * a experiment in anyvc * currently lacks a way to propperly document remote methods * RemoteCaller is a base class for wrappers that call to remote objects via a channel object.method(*k, **kw) translates to channel.send(('method', k, kw)) return channel.receive() the default handling can be overridden by implementing own methods the method self._call_method(name, k, kw) ma * RemoteHandler is a base class for Channel callbacks once can use as convience wrapper around remote objects in order too ease handling messages for each incoming method, k, kw tuple it calls the method on self, unpacking the arguments From holger at merlinux.eu Thu Aug 27 12:17:57 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 27 Aug 2009 12:17:57 +0200 Subject: [py-dev] 1.0.2 released / some 1.1 planning notes Message-ID: <20090827101757.GQ15455@trillke.net> Hi all, i just released a pylib/py.test 1.0.2 fixing a number of packaging issues, triggered by fedora packaging issues. I also added a link to the new pytest_django plugin. see the plugin index at http://pylib.org FYI i am currently refactoring and simplifying the code of pylib/py.test and aim for cleaned up mostly-compatible to 1.1 release next month: * featuring cpython 2.4 through to 3.1, jython + pypy compatilibty. * moving the tests out of the lib itself * introducing a way to specify what tests belong to a module/directory (see recent RFC mails) * relicensing to LGPL I'd also like to get the 1.1 flagged issues in the tracker resolved, see http://bitbucket.org/hpk42/py-trunk/issues/?status=new&status=open cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu