From Ronny.Pfannschmidt at gmx.de Thu Oct 1 12:15:23 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Thu, 01 Oct 2009 12:15:23 +0200 Subject: [py-dev] proposal: interaction of execnet nodes and basic node types for execnet based test execution Message-ID: <1254392123.23863.32.camel@localhost> hi, after reading holger's blog post on http://tetamap.wordpress.com/2009/09/26/elastic-python-deployment-networks/ i tought about what kinds of node are necessary/helpfull to deal with test-networks, and how they would interact, as well as some additional cappabilities i'd like to se here my basic outline: reporter they get all the test results in order to store and/or display them collector they run the test collection collecting either all tests or a given subset runner they run every single test case they are given starter they start the actual collect runs on a given node given those node types, one can imply the different execution modes standalone reporter+starter->collector->runner looponfail * like standalone, but collect and run in a different process each run * pass failures as the "given subset" (unless something like SIGHUP/a command tells otherwise) N cpus move runners to N subprocesses instead of being in the same process as the collector multiple platforms/environments at once starters on n environments within the same testnet all that would imply that looponfail sits on a starter, using reporter and collector in order to re-run the failures when file-changes are reported what i would like to do on top of that, is hook something like an ide into the testnet that will start continious testing for n opened projects in a testnet, reporting file changes to the testnet and collecting test results for the developer Regards Ronny From holger at merlinux.eu Thu Oct 1 18:51:15 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 1 Oct 2009 18:51:15 +0200 Subject: [py-dev] execnet now standalone / new web page mailing lists ... Message-ID: <20091001165114.GG15455@trillke.net> Hi all, so i've split out execnet into its own standalone independent package and its own web site using Sphinx, see here: http://codespeak.net/execnet Migrating from existing "py.execnet.*" usage should be as easy as replacing "py.execnet." with "execnet." and importing 'execnet' instead of 'py'. I also uploaded a 1.0.0alpha release to PyPI which you should be able to use for installation. This supports Python2.4-3.1. It should not require setuptools, btw. Also for everyone interested in current and future execnet please subscribe to the new mailing lists: http://codespeak.net/mailman/execnet-dev http://codespeak.net/mailman/execnet-commit Next i plan to deprecate "py.execnet.*" on the py-trunk and point to this new API-compatible package. And then head for a pylib/py.test release and a final execnet one. happy about feedback, as always. cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From issues-noreply at bitbucket.org Sun Oct 4 16:31:06 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sun, 04 Oct 2009 14:31:06 -0000 Subject: [py-dev] New issue 52 in py-trunk: lack of mock objects Message-ID: New issue 52: lack of mock objects http://bitbucket.org/hpk42/py-trunk/issue/52/lack-of-mock-objects RonnyPfannschmidt on Sun, 4 Oct 2009 16:31:06 +0200: Description: i see some need to have mock objects most recent case for me would be emulating execnet channels for disconnected tests of my anyvc remote protocol handlers Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From fijall at gmail.com Tue Oct 6 10:04:10 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 6 Oct 2009 02:04:10 -0600 Subject: [py-dev] execnet now standalone / new web page mailing lists ... In-Reply-To: <20091001165114.GG15455@trillke.net> References: <20091001165114.GG15455@trillke.net> Message-ID: <693bc9ab0910060104j4365619cje27102163030b885@mail.gmail.com> > > ? ?http://codespeak.net/mailman/execnet-dev > ? ?http://codespeak.net/mailman/execnet-commit > Hey. As of now this URLs return 404 for me. Correct URLs are: http://codespeak.net/mailman/listinfo/execnet-dev http://codespeak.net/mailman/listinfo/execnet-commit Cheers, fijal From holger at merlinux.eu Tue Oct 6 10:45:11 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 6 Oct 2009 10:45:11 +0200 Subject: [py-dev] execnet now standalone / new web page mailing lists ... In-Reply-To: <693bc9ab0910060104j4365619cje27102163030b885@mail.gmail.com> References: <20091001165114.GG15455@trillke.net> <693bc9ab0910060104j4365619cje27102163030b885@mail.gmail.com> Message-ID: <20091006084511.GT15455@trillke.net> On Tue, Oct 06, 2009 at 02:04 -0600, Maciej Fijalkowski wrote: > > > > ? ?http://codespeak.net/mailman/execnet-dev > > ? ?http://codespeak.net/mailman/execnet-commit > > > > Hey. As of now this URLs return 404 for me. Correct URLs are: > > http://codespeak.net/mailman/listinfo/execnet-dev > http://codespeak.net/mailman/listinfo/execnet-commit upsie. thanks for the correction! holger From fede.naum at gmail.com Wed Oct 7 08:21:32 2009 From: fede.naum at gmail.com (Fede Naum) Date: Wed, 7 Oct 2009 17:21:32 +1100 Subject: [py-dev] py.test from inside the python console Message-ID: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> Hello, I did a search by subject in the py-dev Archives and could not found any thread about that. I guess it is because the documentation clearly say "py.test is a *command line tool* to collect and run automated tests". I'm using as it is for some integration test but now I want to use it to run them from inside a python shell Is there a way to run the autodiscovery + run the test + get the report from inside a python console? Why do I need that? I need it because I have to do it from inside a special console (the python console provided with Maya - http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897) so I do not have any command line environmet to run py.test Thanks in advance Fede -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20091007/0906eb5c/attachment.htm From holger at merlinux.eu Thu Oct 8 13:47:04 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 8 Oct 2009 13:47:04 +0200 Subject: [py-dev] py.test from inside the python console In-Reply-To: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> Message-ID: <20091008114704.GZ15455@trillke.net> Hi Fede, On Wed, Oct 07, 2009 at 17:21 +1100, Fede Naum wrote: > Hello, I did a search by subject in the py-dev Archives and could not found > any thread about that. > I guess it is because the documentation clearly say "py.test is a *command > line tool* to collect and run automated tests". somewhat true :) > I'm using as it is for some integration test but now I want to use it to run > them from inside a python shell > Is there a way to run the autodiscovery + run the test + get the report from > inside a python console? I've attached a small "runtesthelper.py" script whose "pytest" function you could import into your environment, best through PYTHONSTARTUP. It's a bit of a hack because of "py.test.config" has some global state (using that config object is btw deprecated). > Why do I need that? > I need it because I have to do it from inside a special console (the python > console provided with Maya - > http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897) so > I do not have any command line environmet to run py.test makes sense. Let us now if the above works well enough and/or what you'd like to see. I'd like to see usage-from-the shell get fully supported by default. best, holger From holger at merlinux.eu Thu Oct 8 13:48:17 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 8 Oct 2009 13:48:17 +0200 Subject: [py-dev] py.test from inside the python console In-Reply-To: <20091008114704.GZ15455@trillke.net> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> <20091008114704.GZ15455@trillke.net> Message-ID: <20091008114817.GE31662@trillke.net> and here is the file actually attached. holger On Thu, Oct 08, 2009 at 13:47 +0200, holger krekel wrote: > Hi Fede, > > On Wed, Oct 07, 2009 at 17:21 +1100, Fede Naum wrote: > > Hello, I did a search by subject in the py-dev Archives and could not found > > any thread about that. > > I guess it is because the documentation clearly say "py.test is a *command > > line tool* to collect and run automated tests". > > somewhat true :) > > > I'm using as it is for some integration test but now I want to use it to run > > them from inside a python shell > > Is there a way to run the autodiscovery + run the test + get the report from > > inside a python console? > > I've attached a small "runtesthelper.py" script whose "pytest" function > you could import into your environment, best through PYTHONSTARTUP. > It's a bit of a hack because of "py.test.config" has some global state > (using that config object is btw deprecated). > > > Why do I need that? > > I need it because I have to do it from inside a special console (the python > > console provided with Maya - > > http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897) so > > I do not have any command line environmet to run py.test > > makes sense. Let us now if the above works well enough and/or > what you'd like to see. I'd like to see usage-from-the shell > get fully supported by default. > > best, > holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: runtesthelper.py Type: text/x-python Size: 409 bytes Desc: not available Url : http://codespeak.net/pipermail/py-dev/attachments/20091008/f77f4a8d/attachment.py From gnofi at wgen.net Thu Oct 8 18:39:12 2009 From: gnofi at wgen.net (Gregory Nofi) Date: Thu, 8 Oct 2009 12:39:12 -0400 Subject: [py-dev] py.test: funcargs not working with unittest.Testcase subclasses Message-ID: <68B1D18878686F44A3ADC062A4B730E504365128@wgexch05.wgenhq.net> Hello all, I am trying to use the funcargs feature with my unittest.Testcase subclasses but it appears that py.test fails to pass the additional arguments to the unittest test method. I haven't found any discussion of this anywhere, so I'm making my first post here. Here is a simple example-- # ./conftest.py def pytest_funcarg__val1(request): return True def pytest_funcarg__val2(request): return False # ./test_myunittest.py class Test(unittest.TestCase): def test_Name(self, val1, val2): assert (val1 and val2) The result- ================================================= test session starts ================================================= [...snip...] self = def runtest(self): target = self.obj args = self._args > target(*args) E TypeError: test_Name() takes exactly 3 arguments (1 given) C:\Python26\lib\site-packages\py-1.0.2-py2.6.egg\py\test\plugin\pytest_u nittest.py:65: TypeError ============================================== 1 failed in 0.08 seconds =============================================== As you can see, py.test isn't passing the 2 funcargs from conftest.py. However, if you simply remove "unittest.TestCase" from test_myunittest.py, the py.test fails as intended- self = < test_myunittest.py.Test instance at 0x00E98AF8>, val1 = True, val2 = False def test_Name(self, val1, val2): > assert (val1 and val2) E assert (True and False) tests\math\ test_myunittest.py:18: AssertionError ============================================== 1 failed in 0.08 seconds =============================================== Is there any way to incorporate the funcargs feature into the unittest compatibility? Thanks, and keep up the great tool! Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20091008/c6e2aa90/attachment.htm From issues-noreply at bitbucket.org Fri Oct 9 01:33:51 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Thu, 08 Oct 2009 23:33:51 -0000 Subject: [py-dev] New issue 53 in py-trunk: Error during collection Message-ID: <41cee7779cc1a6dc59f0422e1b587c0d@bitbucket.org> New issue 53: Error during collection http://bitbucket.org/hpk42/py-trunk/issue/53/error-during-collection Anonymous on Fri, 9 Oct 2009 01:33:51 +0200: Description: The following test module causes an error during collection: {{{ #!python import unittest class _E(object): def __getattr__(self, tag): pass E = _E() }}} the error: {{{ #!python (default)l-rjones:foo richard$ py.test ================================================================= test session starts ================================================================== python: platform darwin -- Python 2.6.1 test object 1: /private/tmp/foo test_foo.py E ======================================================================== ERRORS ======================================================================== _________________________________________________ ERROR during collection /private/tmp/foo/test_foo.py _________________________________________________ collector = def pytest_make_collect_report(collector): result = excinfo = None try: > result = collector._memocollect() /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/plugin/pytest_runner.py:32: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = def _memocollect(self): """ internal helper method to cache results of calling collect(). """ > return self._memoizedcall('_collected', self.collect) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/collect.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = , attrname = '_collected', function = > def _memoizedcall(self, attrname, function): exattrname = "_ex_" + attrname failure = getattr(self, exattrname, None) if failure is not None: raise failure[0], failure[1], failure[2] if hasattr(self, attrname): return getattr(self, attrname) try: > res = function() /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/collect.py:99: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = def collect(self): l = self._deprecated_collect() if l is not None: return l > name2items = self._buildname2items() /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/pycollect.py:94: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = def _buildname2items(self): # NB. we avoid random getattrs and peek in the __dict__ instead d = {} dicts = [getattr(self.obj, '__dict__', {})] for basecls in py.std.inspect.getmro(self.obj.__class__): dicts.append(basecls.__dict__) seen = {} for dic in dicts: for name, obj in dic.items(): if name in seen: continue seen[name] = True > res = self.makeitem(name, obj) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/pycollect.py:111: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = , name = 'E', obj = def makeitem(self, name, obj): res = self.config.hook.pytest_pycollect_makeitem( > collector=self, name=name, obj=obj) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/pycollect.py:123: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = def __call__(self, **kwargs): methods = self.hookrelay._getmethods(self.name, self.extralookup) mc = MultiCall(methods, kwargs, firstresult=self.firstresult) > return self.hookrelay._performcall(self.name, mc) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/_com.py:120: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = , name = 'pytest_pycollect_makeitem' multicall = , '__multicall__': , 'obj': , 'name': 'E'}> def _performcall(self, name, multicall): > return multicall.execute() /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/_com.py:105: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = , '__multicall__': , 'obj': , 'name': 'E'}> def execute(self): while self.methods: method = self.methods.pop() kwargs = self.getkwargs(method) > res = method(**kwargs) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/_com.py:25: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ collector = , name = 'E', obj = def pytest_pycollect_makeitem(collector, name, obj): if 'unittest' not in sys.modules: return # nobody could have possibly derived a subclass > if py.std.inspect.isclass(obj) and issubclass(obj, py.std.unittest.TestCase): E TypeError: issubclass() arg 1 must be a class /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/plugin/pytest_unittest.py:22: TypeError =============================================================== 1 error in 0.11 seconds ================================================================ }}} with py.test version 1.0.2 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From holger at merlinux.eu Thu Oct 8 13:47:04 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 8 Oct 2009 13:47:04 +0200 Subject: [py-dev] py.test from inside the python console In-Reply-To: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> Message-ID: <20091008114704.GZ15455@trillke.net> Hi Fede, On Wed, Oct 07, 2009 at 17:21 +1100, Fede Naum wrote: > Hello, I did a search by subject in the py-dev Archives and could not found > any thread about that. > I guess it is because the documentation clearly say "py.test is a *command > line tool* to collect and run automated tests". somewhat true :) > I'm using as it is for some integration test but now I want to use it to run > them from inside a python shell > Is there a way to run the autodiscovery + run the test + get the report from > inside a python console? I've attached a small "runtesthelper.py" script whose "pytest" function you could import into your environment, best through PYTHONSTARTUP. It's a bit of a hack because of "py.test.config" has some global state (using that config object is btw deprecated). > Why do I need that? > I need it because I have to do it from inside a special console (the python > console provided with Maya - > http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897) so > I do not have any command line environmet to run py.test makes sense. Let us now if the above works well enough and/or what you'd like to see. I'd like to see usage-from-the shell get fully supported by default. best, holger From issues-noreply at bitbucket.org Sun Oct 11 21:13:57 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sun, 11 Oct 2009 19:13:57 -0000 Subject: [py-dev] New issue 54 in py-trunk: py.process.cmdexec() hangs if stderr is full Message-ID: <5113bf3e637aa55d2ae2b0e5a069320a@bitbucket.org> New issue 54: py.process.cmdexec() hangs if stderr is full http://bitbucket.org/hpk42/py-trunk/issue/54/pyprocesscmdexec-hangs-if-stderr-is-full Victor Stinner / haypo on Sun, 11 Oct 2009 21:13:57 +0200: Description: I'm trying a debug version of PyPy which writes a lot of lines to stderr. After few seconds, PyPy hangs. strace shows that there are two processes: * parent : reading on a pipe (a) * child : writing to a pipe (b) and... pipe (a) and pipe (b) are different. The child is blocked because the pipe (b) is full, and the parent is blocking because there is no data on pipe (a). The problem is in py.process.cmdexec(): def popen3_exec_cmd(cmd): stdin, stdout, stderr = os.popen3(cmd) out = stdout.read() err = stderr.read() stdout.close() stderr.close() stderr is full but the parent is still waiting for the end of stdout (process exit). I think that stdout and stderr should be read at the same time, maybe using non blocking file descriptors and/or select. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From fede.naum at gmail.com Mon Oct 12 07:26:55 2009 From: fede.naum at gmail.com (Fede Naum) Date: Mon, 12 Oct 2009 16:26:55 +1100 Subject: [py-dev] py.test from inside the python console In-Reply-To: <20091008114817.GE31662@trillke.net> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> <20091008114704.GZ15455@trillke.net> <20091008114817.GE31662@trillke.net> Message-ID: <357ef9ea0910112226s23716efbrd650b9c431cfde42@mail.gmail.com> Hi Holger, and all, Thank you so much for the quick response, and sorry I could not come back with the results earlier. The "runtesthelper.py" works fine to run tests in a console and inside Maya without using any plugin. But I need to use the *keyword* plugin because I have to select some test that runs inside maya, and deselect other that run in another application.... I was registering it with the following code. (likely not to be the best way, and as you said it's kind of a hack using py.test.config,) import os, py os.environ['PYTEST_PLUGINS'] = 'keyword' py.test.config.pluginmanager.consider_env() py.test.config.pluginmanager.do_configure(py.test.config) but now when I used the "runtesthelper.py" I got an error, so I could not manage yet to read the keyword plugin and then execute my tests. You were saying that py.test.config is kind of deprecated.?..so, what should I use instead? Or what will be the correct way to register a plugin from inside a console and then run the test using your "runtesthelper.py" Thanks a lot Fede On Thu, Oct 8, 2009 at 10:48 PM, holger krekel wrote: > > and here is the file actually attached. > > holger > > On Thu, Oct 08, 2009 at 13:47 +0200, holger krekel wrote: > > > Hi Fede, > > > > On Wed, Oct 07, 2009 at 17:21 +1100, Fede Naum wrote: > > > Hello, I did a search by subject in the py-dev Archives and could not > found > > > any thread about that. > > > I guess it is because the documentation clearly say "py.test is a > *command > > > line tool* to collect and run automated tests". > > > > somewhat true :) > > > > > I'm using as it is for some integration test but now I want to use it > to run > > > them from inside a python shell > > > Is there a way to run the autodiscovery + run the test + get the report > from > > > inside a python console? > > > > I've attached a small "runtesthelper.py" script whose "pytest" function > > you could import into your environment, best through PYTHONSTARTUP. > > It's a bit of a hack because of "py.test.config" has some global state > > (using that config object is btw deprecated). > > > > > Why do I need that? > > > I need it because I have to do it from inside a special console (the > python > > > console provided with Maya - > > > > http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897) > so > > > I do not have any command line environmet to run py.test > > > > makes sense. Let us now if the above works well enough and/or > > what you'd like to see. I'd like to see usage-from-the shell > > get fully supported by default. > > > > best, > > holger > > -- > Metaprogramming, Python, Testing: http://tetamap.wordpress.com > Python, PyPy, pytest contracting: http://merlinux.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20091012/c8037fa1/attachment.htm From holger at merlinux.eu Mon Oct 12 10:50:15 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 12 Oct 2009 10:50:15 +0200 Subject: [py-dev] py.test from inside the python console In-Reply-To: <357ef9ea0910112226s23716efbrd650b9c431cfde42@mail.gmail.com> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> <20091008114704.GZ15455@trillke.net> <20091008114817.GE31662@trillke.net> <357ef9ea0910112226s23716efbrd650b9c431cfde42@mail.gmail.com> Message-ID: <20091012085015.GM29141@trillke.net> Hi Fede, On Mon, Oct 12, 2009 at 16:26 +1100, Fede Naum wrote: > Hi Holger, and all, Thank you so much for the quick response, and sorry I > could not come back with the results earlier. > > The "runtesthelper.py" works fine to run tests in a console and inside Maya > without using any plugin. > But I need to use the *keyword* plugin because I have to select some test > that runs inside maya, and deselect other that run in another > application.... i think the keyword plugin is enabled by default. When i run runtesthelper.pytest(['--traceconfig', ...]) the keyword plugin should be in the "active plugins" section. > I was registering it with the following code. (likely not to be the best > way, and as you said it's kind of a hack using py.test.config,) > > import os, py > os.environ['PYTEST_PLUGINS'] = 'keyword' > py.test.config.pluginmanager.consider_env() > py.test.config.pluginmanager.do_configure(py.test.config) > > but now when I used the "runtesthelper.py" I got an error, so I could not > manage yet to read the keyword plugin and then execute my tests. If you need to add plugins setting os.environ should be enough. the startup of py.test (even through the runtesthelper script) takes care to load plugins. but again, i think there is no need to load the 'keyword' plugin in particular. > You were saying that py.test.config is kind of deprecated.?..so, what should > I use instead? Or what will be the correct way to register a plugin from > inside a console and then run the test using your "runtesthelper.py" plugin methods can get access to the config object. > Thanks a lot > Fede welcome. holger From fede.naum at gmail.com Tue Oct 13 10:20:36 2009 From: fede.naum at gmail.com (Fede Naum) Date: Tue, 13 Oct 2009 19:20:36 +1100 Subject: [py-dev] py.test from inside the python console In-Reply-To: <20091012085015.GM29141@trillke.net> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> <20091008114704.GZ15455@trillke.net> <20091008114817.GE31662@trillke.net> <357ef9ea0910112226s23716efbrd650b9c431cfde42@mail.gmail.com> <20091012085015.GM29141@trillke.net> Message-ID: <357ef9ea0910130120v4bd89e85p31ae647a8d4a7b5c@mail.gmail.com> Hi Holger, you are absolutely right!!! I was just messing it up with my code. So briefly, it works fine in a console and inside the Maya console using the plugins, so I can now select and deselect the tests... Thanks you so much for you help, and congratulation for the tool, it's being very useful here best regards Fede On 12 October 2009 19:50, holger krekel wrote: > Hi Fede, > > On Mon, Oct 12, 2009 at 16:26 +1100, Fede Naum wrote: > > Hi Holger, and all, Thank you so much for the quick response, and sorry I > > could not come back with the results earlier. > > > > The "runtesthelper.py" works fine to run tests in a console and inside > Maya > > without using any plugin. > > But I need to use the *keyword* plugin because I have to select some test > > that runs inside maya, and deselect other that run in another > > application.... > > i think the keyword plugin is enabled by default. When i run > > runtesthelper.pytest(['--traceconfig', ...]) > > the keyword plugin should be in the "active plugins" section. > > > I was registering it with the following code. (likely not to be the best > > way, and as you said it's kind of a hack using py.test.config,) > > > > import os, py > > os.environ['PYTEST_PLUGINS'] = 'keyword' > > py.test.config.pluginmanager.consider_env() > > py.test.config.pluginmanager.do_configure(py.test.config) > > > > but now when I used the "runtesthelper.py" I got an error, so I could not > > manage yet to read the keyword plugin and then execute my tests. > > If you need to add plugins setting os.environ should be > enough. the startup of py.test (even through the > runtesthelper script) takes care to load plugins. > but again, i think there is no need to load the 'keyword' > plugin in particular. > > > You were saying that py.test.config is kind of deprecated.?..so, what > should > > I use instead? Or what will be the correct way to register a plugin from > > inside a console and then run the test using your "runtesthelper.py" > > plugin methods can get access to the config object. > > > Thanks a lot > > Fede > > welcome. > holger > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20091013/fc857aa1/attachment.htm From 5kycsae02 at sneakemail.com Thu Oct 15 05:56:59 2009 From: 5kycsae02 at sneakemail.com (Simon) Date: 15 Oct 2009 03:56:59 -0000 Subject: [py-dev] Log to a file Message-ID: <31126-32790@sneakemail.com> Hi! I would like to capture the verbose output of test runs to a file so that the debug is captured to a file regardless of whether the test failed or when the test is not running to completion. Is there an easy way of doing this via a command line option, or should I be perhaps modifying the resultlog plugin or something similar? Thanks, Simon From holger at merlinux.eu Thu Oct 15 09:33:18 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 15 Oct 2009 09:33:18 +0200 Subject: [py-dev] Log to a file In-Reply-To: <31126-32790@sneakemail.com> References: <31126-32790@sneakemail.com> Message-ID: <20091015073318.GJ29141@trillke.net> Hi Simon, On Thu, Oct 15, 2009 at 03:56 -0000, Simon wrote: > I would like to capture the verbose output of test runs to a file so that the debug is captured to a file regardless of whether the test failed or when the test is not running to completion. > > Is there an easy way of doing this via a command line option, or should I be perhaps modifying the resultlog plugin or something similar? if you are using unix, you could do: "py.test ... | tee -a log" on windows there might be something similar. Otherwise maybe indeed the resultlog plugin could grow some feature. In fact i'd like to have result logging happen to a directory and then be able to query it without running tests. best, holger From fijall at gmail.com Thu Oct 15 19:31:34 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 15 Oct 2009 11:31:34 -0600 Subject: [py-dev] Log to a file In-Reply-To: <31126-32790@sneakemail.com> References: <31126-32790@sneakemail.com> Message-ID: <693bc9ab0910151031g5e327795m26aff82d7f028eda@mail.gmail.com> On Wed, Oct 14, 2009 at 9:56 PM, Simon <5kycsae02 at sneakemail.com> wrote: > Hi! > > I would like to capture the verbose output of test runs to a file so that the debug is captured to a file regardless of whether the test failed or when the test is not running to completion. > > Is there an easy way of doing this via a command line option, or should I be perhaps modifying the resultlog plugin or something similar? > > Thanks, > > Simon You know about py.test -s right? Cheers, fijal From holger at merlinux.eu Thu Oct 15 21:05:13 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 15 Oct 2009 21:05:13 +0200 Subject: [py-dev] generalized skipping / xfail Message-ID: <20091015190513.GX29141@trillke.net> Hi all, i've just written docs and ported bits of py.test's own test suite to the new "generalized skipping" feature. With it one can mark test functions, classes or modules for conditional skipping ... see here for more details and examples: http://codespeak.net/py/trunk/test/plugin/skipping.html feedback very welcome. best, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From issues-noreply at bitbucket.org Thu Oct 15 22:12:17 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Thu, 15 Oct 2009 20:12:17 -0000 Subject: [py-dev] New issue 55 in py-trunk: Distributed Load Testing Issues Message-ID: <900310c993a972ecf07ba963f5991962@bitbucket.org> New issue 55: Distributed Load Testing Issues http://bitbucket.org/hpk42/py-trunk/issue/55/distributed-load-testing-issues dsaputo on Thu, 15 Oct 2009 22:12:17 +0200: Description: Using the py.test -n option, the txnodes seem to be ready to receive tests. The only way I've seen tests distributed to the nodes is if the tests are all in separate files, e.g. test_spam1.py, test_spam2.py, etc. Even then, it distributes unevenly with some nodes never getting any tests. If there is only one file with multiple tests, e.g. test_spam.py contains test_eggs1(), test_eggs2(), etc., it appears that all tests go to one node. If there are generated tests (using pytest_generate_tests(metafunc)), all these tests also go to one node. Is this the way it works, is this a bug, or am I doing something wrong? Python version 2.6.3 py.test version 1.0.2 Tested on Mac OS X 10.6.1 Windows XP SP2 Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From 5kycsae02 at sneakemail.com Fri Oct 16 01:15:30 2009 From: 5kycsae02 at sneakemail.com (Simon) Date: 15 Oct 2009 23:15:30 -0000 Subject: [py-dev] Log to a file Message-ID: <32401-27404@sneakemail.com> On 16/10/2009, at 04:31 , Maciej Fijalkowski fijall-at-gmail.com |py- dev + execnet-dev| wrote: > On Wed, Oct 14, 2009 at 9:56 PM, Simon <5kycsae02 at sneakemail.com> > wrote: >> Hi! >> >> I would like to capture the verbose output of test runs to a file >> so that the debug is captured to a file regardless of whether the >> test failed or when the test is not running to completion. >> >> Is there an easy way of doing this via a command line option, or >> should I be perhaps modifying the resultlog plugin or something >> similar? >> >> Thanks, >> >> Simon > > You know about py.test -s right? > > Cheers, > fijal Sorry, I wasn't particularly clear. We generally run our tests with the -v option which is fine, which produces a level of output suitable for our general day to day use. However we would also like to log the complete (-s) output to a file in the background. So that if at some point in the future we need to go through the detailed output, it is available. We'd also like this to happen in such a way that if the tests were to hang or hard crash halfway through, we still have the debug log. Any ideas? Simon From holger at merlinux.eu Fri Oct 16 12:23:38 2009 From: holger at merlinux.eu (holger krekel) Date: Fri, 16 Oct 2009 12:23:38 +0200 Subject: [py-dev] Log to a file In-Reply-To: <32401-27404@sneakemail.com> References: <32401-27404@sneakemail.com> Message-ID: <20091016102338.GZ29141@trillke.net> On Thu, Oct 15, 2009 at 23:15 -0000, Simon wrote: > On 16/10/2009, at 04:31 , Maciej Fijalkowski fijall-at-gmail.com |py- > dev + execnet-dev| wrote: > > > On Wed, Oct 14, 2009 at 9:56 PM, Simon <5kycsae02 at sneakemail.com> > > wrote: > >> Hi! > >> > >> I would like to capture the verbose output of test runs to a file > >> so that the debug is captured to a file regardless of whether the > >> test failed or when the test is not running to completion. > >> > >> Is there an easy way of doing this via a command line option, or > >> should I be perhaps modifying the resultlog plugin or something > >> similar? > >> > >> Thanks, > >> > >> Simon > > > > You know about py.test -s right? > > > > Cheers, > > fijal > > Sorry, I wasn't particularly clear. > > We generally run our tests with the -v option which is fine, which > produces a level of output suitable for our general day to day use. > > However we would also like to log the complete (-s) output to a file > in the background. So that if at some point in the future we need to > go through the detailed output, it is available. > > We'd also like this to happen in such a way that if the tests were to > hang or hard crash halfway through, we still have the debug log. > > Any ideas? I am not completely sure how to best implement it. Maybe extend the "--capture" option to specify a filename. A naive implementation would only produce the test output though, not meta-information like test name or traceback. Maybe a bit tricky to get this working for dist-testing like "-n 3" but that's probably true for any impl idea for this feature. what do you think? Capturing is done via code in the _py/test/plugin/pytest_capture.py and in _py/io/capture.py (py-trunk references) - not completely trivial code because it works hard to play nicely with tests/apps using the std logging module which assumes ownership of sys.stdout/stderr stream. Do you feel like giving it a try? I plan for a 1.1 beta1 soon so it could be available soon. best, holger From Ronny.Pfannschmidt at gmx.de Fri Oct 16 18:44:49 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Fri, 16 Oct 2009 18:44:49 +0200 Subject: [py-dev] generalized skipping / xfail In-Reply-To: <20091015190513.GX29141@trillke.net> References: <20091015190513.GX29141@trillke.net> Message-ID: <1255711489.882.1.camel@localhost> On Thu, 2009-10-15 at 21:05 +0200, holger krekel wrote: > Hi all, > > i've just written docs and ported bits of py.test's own test > suite to the new "generalized skipping" feature. With it > one can mark test functions, classes or modules for > conditional skipping ... see here for more details > and examples: > > http://codespeak.net/py/trunk/test/plugin/skipping.html > > feedback very welcome. a few extended examples using funcarg values and/or generate_tests would be very appreciated Regards, Ronny From issues-noreply at bitbucket.org Mon Oct 19 18:14:59 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Mon, 19 Oct 2009 16:14:59 -0000 Subject: [py-dev] New issue 56 in py-trunk: Problems testing modules in namespace package Message-ID: <0624731c60b20c6a790bfbe0a58a80d2@bitbucket.org> New issue 56: Problems testing modules in namespace package http://bitbucket.org/hpk42/py-trunk/issue/56/problems-testing-modules-in-namespace cdent on Mon, 19 Oct 2009 18:14:59 +0200: Description: When using namespace_packages if I am testing a new module in a namespace that is already installed into sys.path (e.g. an egg in that namespace is already on sys.path) then the new module fails to import when running the test file against py.test. If I run the same test file with python (and have the test executed) all goes well and the correct code is imported, and the test passes as expected. While narrowing this down I created a new namespace package and tested it in place (before installing it as an egg). That first test worked fine. I then created a second module in the same namespace and tested it before installing the first module. That tested fine. I then installed the first module. Subsequent tests of the second module failed. I'm in Python 2.6.1, py 1.0.2 on OS X 10.6.1 I have attached a tarball which ought to demonstrate this situation. Inside the tarball are two directories: test.one and test.two. Both contain modules which are destined for the test1234 namespace. As they stand the single test in test dir in each should run just fine. However if 'python setup.py install' is run in the test.one directory, installing test1234.one as egg, the test in test.two will fail to 'from test1234.two import two' (assuming that things don't work). At first glance this makes me think "oh namespace_packages" are yucky, but if you run 'python test/test_two.py' things work fine... Happy to do any additional digging about as required. Thanks. A little more cookbooky on the tarball: * tar zxvf testme.tar.gz * cd testme/test.one * py.test test # expect success * cd ../test.two * py.test test # expect success * cd ../test.one * sudo python setup.py install # install egg * cd ../test.two * py.test test/test_two.py # except failure "E ImportError: No module named two" * python test/test_two.py # expect success Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From issues-noreply at bitbucket.org Tue Oct 20 17:15:59 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Tue, 20 Oct 2009 15:15:59 -0000 Subject: [py-dev] New issue 57 in py-trunk: looponfail traceback on unexpected pass of a xfail test Message-ID: <834292125e6d094baf47bcd02cedd84e@bitbucket.org> New issue 57: looponfail traceback on unexpected pass of a xfail test http://bitbucket.org/hpk42/py-trunk/issue/57/looponfail-traceback-on-unexpected-pass-of-a-xfail RonnyPfannschmidt on Tue, 20 Oct 2009 17:15:59 +0200: Description: trace on http://paste.pocoo.org/show/145976/ Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From fdg001 at gmx.net Tue Oct 20 21:02:47 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Tue, 20 Oct 2009 20:02:47 +0100 Subject: [py-dev] using funcargs for setup/teardown Message-ID: <4ADE0957.7010005@gmx.net> In a brief conversation with Holger today, I confessed that for a long time I couldn't bring myself to properly read up on funcargs. While I appreciate the obvious efforts that have gone into creating the comprehensive documentation*, it did seem just a little intimidating. (Also, I generally prefer reading code to reading prose.) Anyway, I finally played around a bit with funcargs, and it actually turned out to be fairly easy to get started: http://gist.github.com/214495 While those code samples are certainly not perfect, I figured it might be useful to share this naive quickstart approach with the class. I'll need to do more reading to assess whether or how this fits into the existing documentation though. -- Fred * http://codespeak.net/py/dist/test/funcargs.html From holger at merlinux.eu Tue Oct 20 23:09:33 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 20 Oct 2009 23:09:33 +0200 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4ADE0957.7010005@gmx.net> References: <4ADE0957.7010005@gmx.net> Message-ID: <20091020210933.GG29141@trillke.net> Hi Frederik, On Tue, Oct 20, 2009 at 20:02 +0100, Frederik Dohr wrote: > In a brief conversation with Holger today, I confessed that for a long > time I couldn't bring myself to properly read up on funcargs. > While I appreciate the obvious efforts that have gone into creating the > comprehensive documentation*, it did seem just a little intimidating. > (Also, I generally prefer reading code to reading prose.) It contains many examples and also a reference for the API. I consider splitting the two aspects. > Anyway, I finally played around a bit with funcargs, and it actually > turned out to be fairly easy to get started: > http://gist.github.com/214495 > > While those code samples are certainly not perfect, I figured it might > be useful to share this naive quickstart approach with the class. > I'll need to do more reading to assess whether or how this fits into the > existing documentation though. nice for understand setup - but i wonder. If py.test did some basic logging that shows which user code is invoked when (e.g. test function, setup functions, funcarg factories, plugin or conftest hooks ...) it would make such help-examples smaller and more focused. With "user code" i mean code invoked from the test tool. Below is a try at explaining funcargs from a "read-source" perspective. best & thanks for the feedback, holger A minimal example for using a funcarg begins like this:: def test_logging(tmpdir): p = tmpdir.mkdir("example") The 'tmpdir' is an empty temporary directory unique per test function. Let's use another funcarg to monkey-patch an environment variable and then do a test that our application honours it:: def test_logging(tmpdir, monkeypatch): p = tmpdir.join("logfile") monkeypatch.setenv('LOGFILE', p) ... call app which does logging ... s = p.read() assert "startup..." in s Both the tmpdir and the monkeypatch values are created from their respective funcarg factory. Here is the monkeypatch funcarg factory: http://bitbucket.org/hpk42/py-trunk/src/d9645744d8a5/_py/test/plugin/pytest_monkeypatch.py From holger at merlinux.eu Thu Oct 22 21:15:31 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 22 Oct 2009 21:15:31 +0200 Subject: [py-dev] pending py.test-1.1.0b1 / advanced skipping Message-ID: <20091022191531.GU29141@trillke.net> Hi all, Next week I'd like to package a 1.1b1 release working well with CPython 2.4-3.1, pypy and Jython. My intention is for it to be major cleanup release, backward compatible but deprecating old stuff. It will also introduce a few new features and refinements, among them generalized skipping: http://codespeak.net/py/trunk/test/plugin/skipping.html If you have any feedback or comments on this, i am happy to hear them. Bitbuckets py-trunk repo has the working code - and i am also hanging around on #pylib on freenode usually. cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From issues-noreply at bitbucket.org Fri Oct 23 10:40:29 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Fri, 23 Oct 2009 08:40:29 -0000 Subject: [py-dev] New issue 58 in py-trunk: py.test broken with use of multiprocessing.Process Message-ID: <3c4a3d8cf7050808d9f44481ecfba597@bitbucket.org> New issue 58: py.test broken with use of multiprocessing.Process http://bitbucket.org/hpk42/py-trunk/issue/58/pytest-broken-with-use-of bluebird75 on Fri, 23 Oct 2009 10:40:28 +0200: Description: The following program clearly highlights the problem: {{{ #!python import os from multiprocessing import Process def do_task1(): print 'task1: pid=%d' % (os.getpid()) class TestProcess: def test_p1( self ): print 'test_p1: pid=%d' % os.getpid() p = Process( name='p1', target=do_task1 ) p.start() p.join() }}} Philippe at pc-philippe /cygdrive/d/work/elc-dev/tmp $ py.test -s ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=3920 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=3344 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=208 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=3364 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=536 ... As you can see, Process() is restarting py.test instead of starting the target function. This is on windows XP, python 2.6.1 . Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From fdg001 at gmx.net Sun Oct 25 15:01:45 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Sun, 25 Oct 2009 14:01:45 +0000 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <20091020210933.GG29141@trillke.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> Message-ID: <4AE45A49.70207@gmx.net> > It contains many examples and also a reference for the API. > I consider splitting the two aspects. That's probably a good idea. > If py.test did some basic logging that shows which user code is > invoked when (e.g. test function, setup functions, funcarg > factories, plugin or conftest hooks ...) it would make such > help-examples smaller and more focused. > [...] > Below is a try at explaining funcargs from a "read-source" perspective. Unfortunately, I cannot relate to this - likely due to my overall ignorance when it comes to funcargs. However, I've finally figured out why I'm having such a hard time warming up to funcargs: They go way beyond the minimalist simplicity that made me switch to py.test in the first place. (I realize there's some Magic to py.test's internals, but that doesn't surface in the API.) Funcargs seem like a departure from this principle. I understand that some situations demand such complexity, so I'm not arguing against funcargs in general - but for my part, I've managed to keep it simple so far. All of this is to say that I'm happy enough with this for setup and teardown*, but I'm probably the wrong person to comment on anything beyond that. -- F. * although I'm considering writing two decorators to easily turn any function into a setup or teardown method From fdg001 at gmx.net Sun Oct 25 19:28:21 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Sun, 25 Oct 2009 18:28:21 +0000 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4AE45A49.70207@gmx.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE45A49.70207@gmx.net> Message-ID: <4AE498C5.4000304@gmx.net> > I'm considering writing two decorators to easily turn any function > into a setup or teardown method That's done now: http://gist.github.com/214495 It was a good learning experience, and as such probably not flawless. (It's certainly more obscure than I'd like... ) -- F. From holger at merlinux.eu Mon Oct 26 11:26:28 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 26 Oct 2009 11:26:28 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4AE459EC.805@gmx.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE459EC.805@gmx.net> Message-ID: <20091026102628.GB29141@trillke.net> Hi Frederik! On Sun, Oct 25, 2009 at 14:00 +0000, Frederik Dohr wrote: >> It contains many examples and also a reference for the API. I consider >> splitting the two aspects. > > That's probably a good idea. > >> If py.test did some basic logging that shows which user code is >> invoked when (e.g. test function, setup functions, funcarg >> factories, plugin or conftest hooks ...) it would make such >> help-examples smaller and more focused. >> [...] >> Below is a try at explaining funcargs from a "read-source" perspective. >> > > Unfortunately, I cannot relate to this - likely due to my overall > ignorance when it comes to funcargs. > > However, I've finally figured out why I'm having such a hard time > warming up to funcargs: They go way beyond the minimalist simplicity > that made me switch to py.test in the first place. > (I realize there's some Magic to py.test's internals, but that doesn't > surface in the API.) > > Funcargs seem like a departure from this principle. > I understand that some situations demand such complexity, so I'm not > arguing against funcargs in general - but for my part, I've managed to > keep it simple so far. I don't want to argue "simplicity" but let me state my perspective and considerations - maybe they shed some light on why i consider the funcargs approach more powerful: test functions are Python functions. Python functions need certain objects to run. Why now use degraded Python functions for tests, i.e. ones that never receives parameters? This implies having to call magic methods for setting up objects in global namespaces or 'self' attributes - which not only makes the test harder to understand and refactor IMO. It also means that setups for different aspects, e.g. mocking a database and mocking a web service intermingle in one setup area whereas funcarg factories allow to keep such setup aspects totally separate and reuseable across the whole test suite. > All of this is to say that I'm happy enough with this for setup and > teardown*, but I'm probably the wrong person to comment on anything > beyond that. i disagree also here a bit - rather appreciate your feedback :) cheers, holger From holger at merlinux.eu Mon Oct 26 12:19:46 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 26 Oct 2009 12:19:46 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4AE498C5.4000304@gmx.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE45A49.70207@gmx.net> <4AE498C5.4000304@gmx.net> Message-ID: <20091026111945.GD29141@trillke.net> On Sun, Oct 25, 2009 at 18:28 +0000, Frederik Dohr wrote: > > I'm considering writing two decorators to easily turn any function > > into a setup or teardown method > > That's done now: > http://gist.github.com/214495 > > It was a good learning experience, and as such probably not flawless. > (It's certainly more obscure than I'd like... ) not sure i see the need for funcargs with this example - why don't you use the "traditional" setup_module/teardown_module functions? (see http://codespeak.net/py/dist/test/xunit_setup.html) best, holger From 5kycsae02 at sneakemail.com Wed Oct 28 08:22:09 2009 From: 5kycsae02 at sneakemail.com (Simon) Date: 28 Oct 2009 07:22:09 -0000 Subject: [py-dev] Log to a file Message-ID: <21883-03418@sneakemail.com> On 16/10/2009, at 21:23 , holger krekel holger-at-merlinux.eu |py-dev + execnet-dev| wrote: > On Thu, Oct 15, 2009 at 23:15 -0000, Simon wrote: >> On 16/10/2009, at 04:31 , Maciej Fijalkowski fijall-at-gmail.com |py- >> dev + execnet-dev| wrote: >> >>> On Wed, Oct 14, 2009 at 9:56 PM, Simon <5kycsae02 at sneakemail.com> >>> wrote: >>>> Hi! >>>> >>>> I would like to capture the verbose output of test runs to a file >>>> so that the debug is captured to a file regardless of whether the >>>> test failed or when the test is not running to completion. >>>> >>>> Is there an easy way of doing this via a command line option, or >>>> should I be perhaps modifying the resultlog plugin or something >>>> similar? >>>> >>>> Thanks, >>>> >>>> Simon >>> >>> You know about py.test -s right? >>> >>> Cheers, >>> fijal >> >> Sorry, I wasn't particularly clear. >> >> We generally run our tests with the -v option which is fine, which >> produces a level of output suitable for our general day to day use. >> >> However we would also like to log the complete (-s) output to a file >> in the background. So that if at some point in the future we need to >> go through the detailed output, it is available. >> >> We'd also like this to happen in such a way that if the tests were to >> hang or hard crash halfway through, we still have the debug log. >> >> Any ideas? > > I am not completely sure how to best implement it. Maybe extend the > "--capture" option to specify a filename. A naive implementation > would > only produce the test output though, not meta-information like test > name > or traceback. Maybe a bit tricky to get this working for dist- > testing like > "-n 3" but that's probably true for any impl idea for this feature. > > what do you think? > > Capturing is done via code in the _py/test/plugin/pytest_capture.py > and > in _py/io/capture.py (py-trunk references) - not completely trivial > code > because it works hard to play nicely with tests/apps using the > std logging module which assumes ownership of sys.stdout/stderr > stream. > Do you feel like giving it a try? > > I plan for a 1.1 beta1 soon so it could be available soon. > > best, > holger Hi Holger, I started looking into this a bit but ran into a problem when I started to probe the py.io module. I tried running the py.io examples on the website but when I run the py.io.StdCaptureFD example, python dies on the second line: stakita at okum:~$ 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. History restored: /auto/home/stakita/.pyhistory, Max Length: 500 >>> import py, sys >>> capture = py.io.StdCaptureFD() stakita at okum:~$ My guess is that an exception is being thrown, but the captured sys.stderr descriptor is not passing any meaningful traceback. I tried wrapping the call in try/except, but that didn't seem to help. On the positive side, the problem appears to be quite reproducible. Any ideas on what is going on here? Regards, Simon Sysinfo: stakita at okum:~$ uname -a Linux okum 2.6.28-15-generic #51-Ubuntu SMP Mon Aug 31 13:33:16 UTC 2009 i686 GNU/Linux stakita at okum:~$ 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. History restored: /auto/home/stakita/.pyhistory, Max Length: 500 >>> import py >>> py.version '1.0.2' From phil at freehackers.org Wed Oct 28 08:09:34 2009 From: phil at freehackers.org (Philippe Fremy) Date: Wed, 28 Oct 2009 08:09:34 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <20091026102628.GB29141@trillke.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE459EC.805@gmx.net> <20091026102628.GB29141@trillke.net> Message-ID: <4AE7EE2E.1020208@freehackers.org> holger krekel wrote: > Hi Frederik! > >> However, I've finally figured out why I'm having such a hard time >> warming up to funcargs: They go way beyond the minimalist simplicity >> that made me switch to py.test in the first place. >> (I realize there's some Magic to py.test's internals, but that doesn't >> surface in the API.) >> >> Funcargs seem like a departure from this principle. >> I understand that some situations demand such complexity, so I'm not >> arguing against funcargs in general - but for my part, I've managed to >> keep it simple so far. >> I second Frederic here. I chose py.test because of the overall simplicity of the framework when you use it. The setup_module/setup_class/setup_method without any special magic other than using function, class or method names starting with test is really really nice. I am kind of worried because I could no longer find them in the documentation. I eventually found them in the xUnit documentation but that's not where I expected them. I vote for a return of this documentation to the main py.test documentation, and moving funcarg related documentation to an "advanced test setup" section. funcarg seems to be a powerful tool, but really cumbersome to grok. I find the magic trick on the naming with __myargument a bit cumbersome. I would feel more comfortable with a syntax that mimic the setup/teardown used for module, class and methods. > This implies having to call magic methods for setting up objects in > global namespaces or 'self' attributes - which not only makes the test > harder to understand and refactor IMO. I do not agree here. If I have one class with 30 unit test methods, it's easier to setup/teardown the test parameters in two methods for the whole class than modifying 30 test methods to add funcargs arguments. So, while I agree that funcargs certainly has potential, I think you should not force it onto the user and should really stress the two ways of setting up per class or per method parameters. And it would be really nice to figure out a syntax for funcarg that is more in the setup/teardown fashion. I don't see much gain of using : def pytest_funcarg__mysetup(request): return MySetup(request) class TestClass: def test_function(self, mysetup): conn = mysetup.getsshconnection() # work with conn instead of : class TestClass: def setup_class( c ): c.mysetup = MySetup() def test_function(self): conn = c.mysetup.getsshconnection() # work with conn The programming style is different, the second one is traditional OO and will be familiar to anybody coming from C++, Java or other OO world. The second one is playing more on the python capabilities. I don't find it more readable. One can argue about the advantage that each test function can take a different parameter. While true, in my testing experience, I haven't seen a pattern with many different tests taking many different parameters. I usually have groups of 5 to 10 tests taking one kind of parameter. If they need to take another kind of parameter, I will put them in a different test class. So, in my opinion, using funcargs for regular cases is a matter of style. I do see a big value in funcargs for the parameterized tests. Running the same test over and over with different parameter is a really nice feature. I think you should stress it more in the documentation. cheers, Philippe From holger at merlinux.eu Wed Oct 28 09:44:00 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 28 Oct 2009 09:44:00 +0100 Subject: [py-dev] Log to a file In-Reply-To: <21883-03418@sneakemail.com> References: <21883-03418@sneakemail.com> Message-ID: <20091028084400.GG29141@trillke.net> On Wed, Oct 28, 2009 at 07:22 -0000, Simon wrote: > On 16/10/2009, at 21:23 , holger krekel holger-at-merlinux.eu |py-dev > >> We'd also like this to happen in such a way that if the tests were to > >> hang or hard crash halfway through, we still have the debug log. > >> > >> Any ideas? > > > > I am not completely sure how to best implement it. Maybe extend the > > "--capture" option to specify a filename. A naive implementation > > would > > only produce the test output though, not meta-information like test > > name > > or traceback. Maybe a bit tricky to get this working for dist- > > testing like > > "-n 3" but that's probably true for any impl idea for this feature. > > > > what do you think? > > > > Capturing is done via code in the _py/test/plugin/pytest_capture.py > > and > > in _py/io/capture.py (py-trunk references) - not completely trivial > > code > > because it works hard to play nicely with tests/apps using the > > std logging module which assumes ownership of sys.stdout/stderr > > stream. > > Do you feel like giving it a try? > > > > I plan for a 1.1 beta1 soon so it could be available soon. > > > > best, > > holger > > Hi Holger, > > I started looking into this a bit but ran into a problem when I > started to probe the py.io module. > > I tried running the py.io examples on the website > but when I run the py.io.StdCaptureFD example, python dies on the > second line: > > stakita at okum:~$ 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. > History restored: /auto/home/stakita/.pyhistory, Max Length: 500 > >>> import py, sys > >>> capture = py.io.StdCaptureFD() The redirect here happens for stdout, stderr and stdin is put to /dev/zero on the file descriptor level ... > stakita at okum:~$ ... so the python interpreter immediately gets an EOL on stdin and dies. > My guess is that an exception is being thrown, but the captured > sys.stderr descriptor is not passing any meaningful traceback. you can call py.io.StdCaptureFD(err=True, in_=False, out=False) and should be able to play with writing to stderr. > I tried wrapping the call in try/except, but that didn't seem to help. > On the positive side, the problem appears to be quite reproducible. > > Any ideas on what is going on here? just anoter recommendation. Maybe it is easiest for you to implement a "--iocapturelog=filename" option and see to send output to it from the pytest_capture plugin on the py-trunk repository. You can start experimenting by copying the pytest_capture.py file somewhere into your import path and modifying it. Your local version will override the builtin one. HTH, holger From phil at freehackers.org Wed Oct 28 10:09:22 2009 From: phil at freehackers.org (Philippe Fremy) Date: Wed, 28 Oct 2009 10:09:22 +0100 Subject: [py-dev] py.test : setup / teardown at the directory level In-Reply-To: <20090428180200.GO11963@trillke.net> References: <49F6EA81.2070106@freehackers.org> <20090428115556.GJ11963@trillke.net> <49F71C0E.3000800@freehackers.org> <20090428180200.GO11963@trillke.net> Message-ID: <4AE80A42.5030009@freehackers.org> holger krekel wrote: > Hi Philippe, > > your described use case makes lots of sense to me. > > I coded an example which i hope fits it. > > It uses the new "local plugins" (i.e. plugins defined in a > conftest.py) and funcargs, if you don't know about them > yet i hope this is good to skim/read first: > http://codespeak.net/py/trunk/test/funcargs.html > > Here is the example: > > http://bitbucket.org/hpk42/py-trunk/src/tip/example/funcarg/lazysetup/ > > using py-trunk (probably also works with the 1.0.0b1, haven't checked) > in the lazysetup directory you can now do > > py.test sub1 # will wait 5 seconds because test > # functions access the setup defined in > # conftest.py > > py.test sub2 # will immediately run as the "setup" > # funcarg is not requested > > The idea for this conftest.py implementation is simple: > setup the funcarg when first needed and only tear it down > when the test process exits. > > does this make sense to you? feel free to play around > and ask questions - I'd then put the above example into > the "tutorial" example section of the funcarg doc. > > One advantage of the above approach is that you do not > need to do anything in your test modules anymore > (no boilerplate importing of setup_module etc.) > than requesting the object you want to setup. > I am reviving this old thread. Honestly, I haven't tried the funcargs based solution that you propose. The reasons are : - I would really prefer to have setup/teardown at directory level and your solution is more per-session level - I don't like the idea of modifying 100 tests just to get a setup/teardown effect - I still find funcargs a bit cumbersome as explained in my other mail. I had a quick look at the plugin architecture to see if I could implement an equivalent of setup/teardown at directory level, but I don't think it's possible. Can you consider this as a feature request ? cheers, Philippe From 5kycsae02 at sneakemail.com Thu Oct 29 07:42:17 2009 From: 5kycsae02 at sneakemail.com (Simon) Date: Thu, 29 Oct 2009 17:42:17 +1100 Subject: [py-dev] Log to a file In-Reply-To: <20091028084400.GG29141@trillke.net> References: <21883-03418@sneakemail.com> <20091028084400.GG29141@trillke.net> Message-ID: <18738-78272@sneakemail.com> On 28/10/2009, at 19:44 , holger krekel holger-at-merlinux.eu |py-dev + execnet-dev| wrote: >> Hi Holger, >> >> I started looking into this a bit but ran into a problem when I >> started to probe the py.io module. >> >> I tried running the py.io examples on the website >> but when I run the py.io.StdCaptureFD example, python dies on the >> second line: >> >> stakita at okum:~$ 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. >> History restored: /auto/home/stakita/.pyhistory, Max Length: 500 >>>>> import py, sys >>>>> capture = py.io.StdCaptureFD() > > The redirect here happens for stdout, stderr and stdin is put to > /dev/zero on the file descriptor level ... > >> stakita at okum:~$ > > ... so the python interpreter immediately gets an EOL on stdin and > dies. So does this mean that the example is a bit broken then? >> My guess is that an exception is being thrown, but the captured >> sys.stderr descriptor is not passing any meaningful traceback. > > you can call py.io.StdCaptureFD(err=True, in_=False, > out=False) and should be able to play with writing to stderr. > >> I tried wrapping the call in try/except, but that didn't seem to >> help. >> On the positive side, the problem appears to be quite reproducible. >> >> Any ideas on what is going on here? > > just anoter recommendation. Maybe it is easiest for you to implement > a "--iocapturelog=filename" option and see to send output to > it from the pytest_capture plugin on the py-trunk repository. > You can start experimenting by copying the pytest_capture.py > file somewhere into your import path and modifying it. Your > local version will override the builtin one. > > HTH, > holger Thanks for the suggestion, and here is a first pass. Attached is a modified version of pytest_capture.py from the 1.0.2 release. In this file, I just push the options into the CaptureManager so that the command line args are available. This does mean that the config file options stuff is not hooked up, but at least it works from the command line at the moment. Additional plugin command line options are: --log-file When used with the two capture options ('fd' and 'sys') this will enable pushing the stdout and stderr writes to the specified file. --append-log This allows appending to the file as opposed to the default clobber behaviour. Does this fit with your model of how the plugin should be structured? Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20091029/bb855e1b/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: pytest_capture.py Type: text/x-python-script Size: 11688 bytes Desc: not available Url : http://codespeak.net/pipermail/py-dev/attachments/20091029/bb855e1b/attachment.bin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20091029/bb855e1b/attachment-0001.htm From pedronis at openend.se Thu Oct 29 17:34:55 2009 From: pedronis at openend.se (Samuele Pedroni) Date: Thu, 29 Oct 2009 17:34:55 +0100 Subject: [py-dev] is anybody seeing this kind of explosion? Message-ID: <4AE9C42F.7040006@openend.se> py lib trunk is exploding this way for me right now, I removed pyc files btw pedronis at vitaly:~/scratch/jskit-nightly$ /u/pedronis/vjskit/bin/python py-trunk/py/bin/py.test --help inserting into sys.path: /u/pedronis/scratch/jskit-nightly/py-trunk Traceback (most recent call last): File "py-trunk/py/bin/py.test", line 3, in py.cmdline.pytest() File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/cmdline.py", line 11, in main config = py.test.config File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 56, in __getattr__ result = importobj(modpath, attrname) File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 23, in importobj module = __import__(modpath, None, None, ['__doc__']) File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/config.py", line 2, in from _py.test.conftesthandle import Conftest File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/conftesthandle.py", line 2, in defaultconftestpath = py.path.local(__file__).dirpath("defaultconftest.py") File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/path/local.py", line 135, in __new__ elif isinstance(path, py.builtin._basestring): File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 56, in __getattr__ result = importobj(modpath, attrname) File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 24, in importobj return getattr(module, attrname) AttributeError: 'module' object has no attribute '_basestring' From holger at merlinux.eu Fri Oct 30 00:42:11 2009 From: holger at merlinux.eu (holger krekel) Date: Fri, 30 Oct 2009 00:42:11 +0100 Subject: [py-dev] is anybody seeing this kind of explosion? In-Reply-To: <4AE9C42F.7040006@openend.se> References: <4AE9C42F.7040006@openend.se> Message-ID: <20091029234211.GK29141@trillke.net> On Thu, Oct 29, 2009 at 17:34 +0100, Samuele Pedroni wrote: > py lib trunk is exploding this way for me right now, I removed pyc files btw is this maybe an empty py/builtin directory? ("bin/py.cleanup" -d should remove empty directories with a recent checkout) holger > pedronis at vitaly:~/scratch/jskit-nightly$ /u/pedronis/vjskit/bin/python > py-trunk/py/bin/py.test --help > inserting into sys.path: /u/pedronis/scratch/jskit-nightly/py-trunk > Traceback (most recent call last): > File "py-trunk/py/bin/py.test", line 3, in > py.cmdline.pytest() > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/cmdline.py", > line 11, in main > config = py.test.config > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line > 56, in __getattr__ > result = importobj(modpath, attrname) > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line > 23, in importobj > module = __import__(modpath, None, None, ['__doc__']) > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/config.py", > line 2, in > from _py.test.conftesthandle import Conftest > File > "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/conftesthandle.py", > line 2, in > defaultconftestpath = > py.path.local(__file__).dirpath("defaultconftest.py") > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/path/local.py", > line 135, in __new__ > elif isinstance(path, py.builtin._basestring): > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line > 56, in __getattr__ > result = importobj(modpath, attrname) > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line > 24, in importobj > return getattr(module, attrname) > AttributeError: 'module' object has no attribute '_basestring' > > > _______________________________________________ > 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 Tue Nov 3 21:52:41 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 3 Nov 2009 21:52:41 +0100 Subject: [py-dev] execnet-1.0.0b1 released: now with Python3/Jython support Message-ID: <20091103205241.GO29141@trillke.net> Hi everybody! i just uploaded a first public release of execnet, namely 1.0.0b1 to PyPI. Grab it with easy_install/pip and your favourite Python environment (no setuptools or distribute required). execnet allows to ad-hoc instantiate local and remote Python interpreters, currently Python2.4, 2.5, 2.6 and (new) also Python 3.1, Jython and PyPy-c. It works on Windows, Linux and OSX and is licensed under the GPL V2 or later. With execnet you can instantiate "gateways" between Python processes, use "remote_exec" code execution and "channels" to perform structured data communication. See here for more info: http://codespeak.net/execnet Here is a list of changes from the rather internal 1.0.0alpha2 release: * added new examples for NumPy, Jython, IronPython * improved documentation * include apipkg.py for lazy-importing * integrated new serializer code from Benjamin Peterson * improved support for Jython-2.5.1 have fun and let me know if you have issues, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From holger at merlinux.eu Wed Nov 4 11:34:21 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 4 Nov 2009 11:34:21 +0100 Subject: [py-dev] Log to a file In-Reply-To: <18738-78272@sneakemail.com> References: <21883-03418@sneakemail.com> <20091028084400.GG29141@trillke.net> <18738-78272@sneakemail.com> Message-ID: <20091104103421.GR29141@trillke.net> Hi Simon, i finally got around to look at your plugin ... On Thu, Oct 29, 2009 at 17:42 +1100, Simon wrote: > On 28/10/2009, at 19:44 , holger krekel holger-at-merlinux.eu |py-dev + > execnet-dev| wrote: > >>> Hi Holger, >>> >>> I started looking into this a bit but ran into a problem when I >>> started to probe the py.io module. >>> >>> I tried running the py.io examples on the website >>> but when I run the py.io.StdCaptureFD example, python dies on the >>> second line: >>> >>> stakita at okum:~$ 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. >>> History restored: /auto/home/stakita/.pyhistory, Max Length: 500 >>>>>> import py, sys >>>>>> capture = py.io.StdCaptureFD() >> >> The redirect here happens for stdout, stderr and stdin is put to >> /dev/zero on the file descriptor level ... >> >>> stakita at okum:~$ >> >> ... so the python interpreter immediately gets an EOL on stdin and >> dies. > > So does this mean that the example is a bit broken then? yes, i fixed it in trunk. >>> My guess is that an exception is being thrown, but the captured >>> sys.stderr descriptor is not passing any meaningful traceback. >> >> you can call py.io.StdCaptureFD(err=True, in_=False, >> out=False) and should be able to play with writing to stderr. >> >>> I tried wrapping the call in try/except, but that didn't seem to >>> help. >>> On the positive side, the problem appears to be quite reproducible. >>> >>> Any ideas on what is going on here? >> >> just anoter recommendation. Maybe it is easiest for you to implement >> a "--iocapturelog=filename" option and see to send output to >> it from the pytest_capture plugin on the py-trunk repository. >> You can start experimenting by copying the pytest_capture.py >> file somewhere into your import path and modifying it. Your >> local version will override the builtin one. >> >> HTH, >> holger > > Thanks for the suggestion, and here is a first pass. Attached is a > modified version of pytest_capture.py from the 1.0.2 release. > > In this file, I just push the options into the CaptureManager so that > the command line args are available. This does mean that the config file > options stuff is not hooked up, but at least it works from the command > line at the moment. just using "config.getvalue()" should be fine. "py.test --help-config" then shows the derived ENV/conftest.py settings, btw. > Additional plugin command line options are: > --log-file > When used with the two capture options ('fd' and 'sys') this > will enable pushing the stdout and stderr writes to the specified file. > --append-log > This allows appending to the file as opposed to the default > clobber behaviour. > > Does this fit with your model of how the plugin should be structured? roughly, yes :) some small comments: * the "append-log" option i'd rather encode as "+logfilename" for the capture-file option (goal is to minimize number of cmdline args) just one --capture-file option makes sense * "self.logfd" is actually a file object, not a file descriptor, so better use "self.capture_file" or so. * your code is not Python3 compatible I'd like to include your changes ... could you rework your patch by checking out http://bitbucket.org/hpk42/py-trunk and modifying _py/test/plugin/pytest_capture.py and running and adding tests here: testing/pytest/plugin/test_pytest_capture.py ? FYI on linux/OSX you can do alias py.test='python /path/to/checkout/bin/py.test' alias py.test3='python3 /path/to/checkout/bin/py.test' to easily have the two main py.test runs available ... adding a py.testjython alias is a bonus :) In any case, feel free to ask more questions, also on #pylib freenode. cheers, holger From holger at merlinux.eu Wed Nov 4 18:23:42 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 4 Nov 2009 18:23:42 +0100 Subject: [py-dev] py.test : setup / teardown at the directory level In-Reply-To: <4AE80A42.5030009@freehackers.org> References: <49F6EA81.2070106@freehackers.org> <20090428115556.GJ11963@trillke.net> <49F71C0E.3000800@freehackers.org> <20090428180200.GO11963@trillke.net> <4AE80A42.5030009@freehackers.org> Message-ID: <20091104172342.GU29141@trillke.net> Hi Philippe, On Wed, Oct 28, 2009 at 10:09 +0100, Philippe Fremy wrote: > holger krekel wrote: > > Hi Philippe, > > > > your described use case makes lots of sense to me. > > > > I coded an example which i hope fits it. > > > > It uses the new "local plugins" (i.e. plugins defined in a > > conftest.py) and funcargs, if you don't know about them > > yet i hope this is good to skim/read first: > > http://codespeak.net/py/trunk/test/funcargs.html > > > > Here is the example: > > > > http://bitbucket.org/hpk42/py-trunk/src/tip/example/funcarg/lazysetup/ > > > > using py-trunk (probably also works with the 1.0.0b1, haven't checked) > > in the lazysetup directory you can now do > > > > py.test sub1 # will wait 5 seconds because test > > # functions access the setup defined in > > # conftest.py > > > > py.test sub2 # will immediately run as the "setup" > > # funcarg is not requested > > > > The idea for this conftest.py implementation is simple: > > setup the funcarg when first needed and only tear it down > > when the test process exits. > > > > does this make sense to you? feel free to play around > > and ask questions - I'd then put the above example into > > the "tutorial" example section of the funcarg doc. > > > > One advantage of the above approach is that you do not > > need to do anything in your test modules anymore > > (no boilerplate importing of setup_module etc.) > > than requesting the object you want to setup. > > > I am reviving this old thread. > > Honestly, I haven't tried the funcargs based solution that you propose. > The reasons are : > - I would really prefer to have setup/teardown at directory level and > your solution is more per-session level true, that's currently the case. > - I don't like the idea of modifying 100 tests just to get a > setup/teardown effect Sure. i am thinking about introducing a general "pytest_pyfunc_setup" hook that you could define at project, directory, module or class level and that would be called for setup of each function. > - I still find funcargs a bit cumbersome as explained in my other mail. > > I had a quick look at the plugin architecture to see if I could > implement an equivalent of setup/teardown at directory level, but I > don't think it's possible. Whatever is called for "directory" setup could live in a conftest.py file. The question is how to transfer any "directory" setup state to a module. At first i thought one could write down: # ./conftest.py def setup_module(mod): # will be called for all modules in/below the dir mod.something = "value" but one would expect this to be called for each module and not just once for a whole directory. Now one could perform some directory-level caching but one conceptual issue remains: values would be "magically" injected into the test modules. Do you have ideas about how you'd like the API to work? > Can you consider this as a feature request ? i'd like to get an idea on how this could work at all conceptually. best, holger From holger at merlinux.eu Wed Nov 4 18:57:18 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 4 Nov 2009 18:57:18 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4AE7EE2E.1020208@freehackers.org> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE459EC.805@gmx.net> <20091026102628.GB29141@trillke.net> <4AE7EE2E.1020208@freehackers.org> Message-ID: <20091104175718.GV29141@trillke.net> Hi Philippe, On Wed, Oct 28, 2009 at 08:09 +0100, Philippe Fremy wrote: > holger krekel wrote: > > Hi Frederik! > > > >> However, I've finally figured out why I'm having such a hard time > >> warming up to funcargs: They go way beyond the minimalist simplicity > >> that made me switch to py.test in the first place. > >> (I realize there's some Magic to py.test's internals, but that doesn't > >> surface in the API.) > >> > >> Funcargs seem like a departure from this principle. > >> I understand that some situations demand such complexity, so I'm not > >> arguing against funcargs in general - but for my part, I've managed to > >> keep it simple so far. > >> > I second Frederic here. I chose py.test because of the overall > simplicity of the framework when you use it. The > setup_module/setup_class/setup_method without any special magic other > than using function, class or method names starting with test is really > really nice. I am kind of worried because I could no longer find them in > the documentation. I eventually found them in the xUnit documentation > but that's not where I expected them. I vote for a return of this > documentation to the main py.test documentation, and moving funcarg > related documentation to an "advanced test setup" section. I am worried that newcomers will be confused then. But i see the point of "unhiding" the xUnit documentation. > funcarg seems to be a powerful tool, but really cumbersome to grok. I > find the magic trick on the naming with __myargument a bit cumbersome. I > would feel more comfortable with a syntax that mimic the setup/teardown > used for module, class and methods. It would be easy to also allow explicit registration for factories ala: def pytest_configure(config): config.add_funcarg_factory(name, factoryfunc) but at the time i choose "convention over configuration" and the "__" because Django also uses a similar way to encode values into a function name. > > This implies having to call magic methods for setting up objects in > > global namespaces or 'self' attributes - which not only makes the test > > harder to understand and refactor IMO. > > I do not agree here. If I have one class with 30 unit test methods, it's > easier to setup/teardown the test parameters in two methods for the > whole class than modifying 30 test methods to add funcargs arguments. agreed, i am considering introducing a new hook: def pytest_pyfunc_setup(request): request.cached_setup(setupfunc, teardownfunc, scope="directory") and this hook would be called for each python test function. Here we call the cached_setup helper to help us manage setup/teardown scopes. (see http://tinyurl.com/yfw82l5 for request object attributes which you could pass into your setup/teardown func) It would also mean you could write down: class TestGroup: parameter = 3 def test_method(self): assert self.parametrized_obj ... and implement a pytest_pyfunc_setup() to set a "self.someobj" according to the class-specified parameter. Would this make sense to you? > So, while I agree that funcargs certainly has potential, I think you > should not force it onto the user and should really stress the two ways > of setting up per class or per method parameters. ok, I'll see to work on the docs a bit. > And it would be really nice to figure out a syntax for funcarg that is > more in the setup/teardown fashion. > > I don't see much gain of using : > > def pytest_funcarg__mysetup(request): > return MySetup(request) > > class TestClass: > def test_function(self, mysetup): > conn = mysetup.getsshconnection() > # work with conn > > > instead of : > > class TestClass: > def setup_class( c ): > c.mysetup = MySetup() > > def test_function(self): > conn = c.mysetup.getsshconnection() > # work with conn > > > The programming style is different, the second one is traditional OO and > will be familiar to anybody coming from C++, Java or other OO world. The > second one is playing more on the python capabilities. I don't find it > more readable. If you have setup_module + setup_class + setup_method (+ subclassing!) layers of setup and teardown, things get a bit harder to understand. In >3000 test projects i know off this led to complexity and refactoring difficulties. > One can argue about the advantage that each test function can take a > different parameter. While true, in my testing experience, I haven't > seen a pattern with many different tests taking many different > parameters. I usually have groups of 5 to 10 tests taking one kind of > parameter. If they need to take another kind of parameter, I will put > them in a different test class. These days i sometimes group tests by feature rather than by setup-parameters. E.g. i put two unit-tests and one functional test into a "TestFeature" class. > So, in my opinion, using funcargs for regular cases is a matter of style. > > I do see a big value in funcargs for the parameterized tests. Running > the same test over and over with different parameter is a really nice > feature. I think you should stress it more in the documentation. makes sense. thanks a lot for your feedback! best, holger From holger at merlinux.eu Thu Nov 5 03:34:26 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 5 Nov 2009 03:34:26 +0100 Subject: [py-dev] py-test-1.1.0 candidate Message-ID: <20091105023426.GY29141@trillke.net> Hi folks, i have a candidate tar ball for the 1.1.0 release which i'd like to release final thursday or friday. Could someone easy_install/pip http://merlinux.eu/~hpk/py-1.1.0.tar.gz with a Python2 or Python3 environment and tell me if "py.test -h" and "py.test -v" work? And maybe run it on your test suite that used to work with 1.0.2? Preliminary release announcement and docs are here, btw: http://codespeak.net/py/trunk/announce/release-1.1.0.html best, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From schmir at gmail.com Thu Nov 5 11:10:49 2009 From: schmir at gmail.com (schmir at gmail.com) Date: Thu, 05 Nov 2009 11:10:49 +0100 Subject: [py-dev] py-test-1.1.0 candidate In-Reply-To: <20091105023426.GY29141@trillke.net> (holger krekel's message of "Thu, 5 Nov 2009 03:34:26 +0100") References: <20091105023426.GY29141@trillke.net> Message-ID: <871vkd46za.fsf@muni.brainbot.com> holger krekel writes: > Hi folks, > > i have a candidate tar ball for the 1.1.0 release > which i'd like to release final thursday or friday. > Could someone > > easy_install/pip http://merlinux.eu/~hpk/py-1.1.0.tar.gz > > with a Python2 or Python3 environment and tell me if "py.test -h" > and "py.test -v" work? And maybe run it on your test suite > that used to work with 1.0.2? > This all seems to work. But did you really expect "py.test -v" to break? I've tested with a 64 bit linux running python 2.6.4 and a 32 bit linux running python 2.4.6. I've also run the mwlib test suite and didn't find any issues. ,---- | [py24-test-mwlib] ~/t/ % py.test -v | ================================================================ test session starts ================================================================= | python: platform linux2 -- Python 2.4.6 -- pytest-1.1.0 -- /home/ralf/py24-test-mwlib/bin/python | test object 1: /home/ralf/t | | ================================================================== in 0.00 seconds ================================================================== | [py24-test-mwlib] ~/t/ % py.test -h | usage: py.test [options] [file_or_dir] [file_or_dir] [...] | | options: | -h, --help show this help message and exit | | running and selection options: | -x, --exitfirst exit instantly on first error or failed test. | -k KEYWORD only run test items matching the given space separated | keywords. precede a keyword with '-' to negate. | Terminate the expression with ':' to treat a match as a | signal to run all subsequent tests. | -p PLUGINS load the specified plugin after command line parsing. | --boxed box each test run in a separate process | --capture=method set capturing method during tests: fd (default)|sys|no. | -s shortcut for --capture=no. | --pdb start pdb (the Python debugger) on errors. | --pastebin=mode send failed|all info to Pocoo pastebin service. | | terminal reporting: | -v, --verbose increase verbosity. | -l, --showlocals show locals in tracebacks (disabled by default). | --report=opts comma separated reporting options | --tb=style traceback verboseness (long/short/no). | --fulltrace don't cut any tracebacks (default is to cut). | | test process debugging and configuration: | --basetemp=dir base temporary directory for this test run. | --collectonly only collect tests, don't execute them. | --traceconfig trace considerations of conftest.py files. | --nomagic don't reinterpret asserts, no traceback cutting. | --debug generate and show internal debugging information. | --help-config show available conftest.py and ENV-variable names. | --version display py lib version and import information. | --no-assert disable python assert expression reinterpretation. `---- Regards, - Ralf From holger at merlinux.eu Thu Nov 5 13:07:56 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 5 Nov 2009 13:07:56 +0100 Subject: [py-dev] py-test-1.1.0 candidate In-Reply-To: <871vkd46za.fsf@muni.brainbot.com> References: <20091105023426.GY29141@trillke.net> <871vkd46za.fsf@muni.brainbot.com> Message-ID: <20091105120756.GZ29141@trillke.net> On Thu, Nov 05, 2009 at 11:10 +0100, schmir at gmail.com wrote: > holger krekel writes: > > > Hi folks, > > > > i have a candidate tar ball for the 1.1.0 release > > which i'd like to release final thursday or friday. > > Could someone > > > > easy_install/pip http://merlinux.eu/~hpk/py-1.1.0.tar.gz > > > > with a Python2 or Python3 environment and tell me if "py.test -h" > > and "py.test -v" work? And maybe run it on your test suite > > that used to work with 1.0.2? > > > > This all seems to work. But did you really expect "py.test -v" to break? well, i am most concerned about packaging issues. And actually meant to ask for "--version" even only :) I've tested myself on XP, OSX and Linux with various Python interpreters, both py.test own tests and 3rd party ones. > I've tested with a 64 bit linux running python 2.6.4 and a 32 bit linux > running python 2.4.6. I've also run the mwlib test suite and didn't find > any issues. great, thanks for the feedback. best, holger > ,---- > | [py24-test-mwlib] ~/t/ % py.test -v > | ================================================================ test session starts ================================================================= > | python: platform linux2 -- Python 2.4.6 -- pytest-1.1.0 -- /home/ralf/py24-test-mwlib/bin/python > | test object 1: /home/ralf/t > | > | ================================================================== in 0.00 seconds ================================================================== > | [py24-test-mwlib] ~/t/ % py.test -h > | usage: py.test [options] [file_or_dir] [file_or_dir] [...] > | > | options: > | -h, --help show this help message and exit > | > | running and selection options: > | -x, --exitfirst exit instantly on first error or failed test. > | -k KEYWORD only run test items matching the given space separated > | keywords. precede a keyword with '-' to negate. > | Terminate the expression with ':' to treat a match as a > | signal to run all subsequent tests. > | -p PLUGINS load the specified plugin after command line parsing. > | --boxed box each test run in a separate process > | --capture=method set capturing method during tests: fd (default)|sys|no. > | -s shortcut for --capture=no. > | --pdb start pdb (the Python debugger) on errors. > | --pastebin=mode send failed|all info to Pocoo pastebin service. > | > | terminal reporting: > | -v, --verbose increase verbosity. > | -l, --showlocals show locals in tracebacks (disabled by default). > | --report=opts comma separated reporting options > | --tb=style traceback verboseness (long/short/no). > | --fulltrace don't cut any tracebacks (default is to cut). > | > | test process debugging and configuration: > | --basetemp=dir base temporary directory for this test run. > | --collectonly only collect tests, don't execute them. > | --traceconfig trace considerations of conftest.py files. > | --nomagic don't reinterpret asserts, no traceback cutting. > | --debug generate and show internal debugging information. > | --help-config show available conftest.py and ENV-variable names. > | --version display py lib version and import information. > | --no-assert disable python assert expression reinterpretation. > `---- > > > Regards, > - Ralf > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From holger at merlinux.eu Thu Nov 5 18:00:43 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 5 Nov 2009 18:00:43 +0100 Subject: [py-dev] py.test/pylib 1.1.0 final released Message-ID: <20091105170043.GB29141@trillke.net> Hi, seems like all works fine except for a little pip-install issue so i just updated some docs and loaded a py-1.1.0 final to PyPi. The online release-announcement is here: http://tinyurl.com/yg5ndn3 thanks to all who helped in the process! best, holger py.test/pylib 1.1.0: Python3, Jython, advanced skipping, cleanups ... -------------------------------------------------------------------------------- Features: * compatible to Python3 (single py2/py3 source), `easy to install`_ * generalized marking_: mark tests one a whole-class or whole-module basis * conditional skipping_: skip/xfail based on platform/dependencies Fixes: * code reduction and "de-magification" (e.g. 23 KLoc -> 11 KLOC) * distribute testing requires the now separately released execnet_ package * funcarg-setup/caching, "same-name" test modules now cause an exlicit error * de-cluttered reporting options, --report for skipped/xfail details Compatibilities 1.1.0 should allow running test code that already worked well with 1.0.2 plus some more due to improved unittest/nose compatibility. More information: http://pytest.org thanks and have fun, holger (http://twitter.com/hpk42) .. _execnet: http://codespeak.net/execnet .. _`easy to install`: ../install.html .. _marking: ../test/plugin/mark.html .. _skipping: ../test/plugin/skipping.html Changelog 1.0.2 -> 1.1.0 ----------------------------------------------------------------------- * remove py.rest tool and internal namespace - it was never really advertised and can still be used with the old release if needed. If there is interest it could be revived into its own tool i guess. * fix issue48 and issue59: raise an Error if the module from an imported test file does not seem to come from the filepath - avoids "same-name" confusion that has been reported repeatedly * merged Ronny's nose-compatibility hacks: now nose-style setup_module() and setup() functions are supported * introduce generalized py.test.mark function marking * reshuffle / refine command line grouping * deprecate parser.addgroup in favour of getgroup which creates option group * add --report command line option that allows to control showing of skipped/xfailed sections * generalized skipping: a new way to mark python functions with skipif or xfail at function, class and modules level based on platform or sys-module attributes. * extend py.test.mark decorator to allow for positional args * introduce and test "py.cleanup -d" to remove empty directories * fix issue #59 - robustify unittest test collection * make bpython/help interaction work by adding an __all__ attribute to ApiModule, cleanup initpkg * use MIT license for pylib, add some contributors * remove py.execnet code and substitute all usages with 'execnet' proper * fix issue50 - cached_setup now caches more to expectations for test functions with multiple arguments. * merge Jarko's fixes, issue #45 and #46 * add the ability to specify a path for py.lookup to search in * fix a funcarg cached_setup bug probably only occuring in distributed testing and "module" scope with teardown. * many fixes and changes for making the code base python3 compatible, many thanks to Benjamin Peterson for helping with this. * consolidate builtins implementation to be compatible with >=2.3, add helpers to ease keeping 2 and 3k compatible code * deprecate py.compat.doctest|subprocess|textwrap|optparse * deprecate py.magic.autopath, remove py/magic directory * move pytest assertion handling to py/code and a pytest_assertion plugin, add "--no-assert" option, deprecate py.magic namespaces in favour of (less) py.code ones. * consolidate and cleanup py/code classes and files * cleanup py/misc, move tests to bin-for-dist * introduce delattr/delitem/delenv methods to py.test's monkeypatch funcarg * consolidate py.log implementation, remove old approach. * introduce py.io.TextIO and py.io.BytesIO for distinguishing between text/unicode and byte-streams (uses underlying standard lib io.* if available) * make py.unittest_convert helper script available which converts "unittest.py" style files into the simpler assert/direct-test-classes py.test/nosetests style. The script was written by Laura Creighton. * simplified internal localpath implementation -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From py-dev at tolomea.com Fri Nov 6 07:11:40 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Fri, 6 Nov 2009 17:11:40 +1100 Subject: [py-dev] unclean shutdown of py.test Message-ID: Short form: I have a test that in some circumstances can't raise an exception, all it can do is call stuff. Currently it calls sys.exit, which is less than optimal. Is there a function or series of functions I can call to somewhat cleanly shutdown py.test in this situation. Longer form: First It is worth noting that we always run py.test with -x, I suspect that will have some bearing on what follows.. The application I'm testing calls a bunch of C code via ctypes. In the event of certain pathological failures that C code does an internal error operation equivalent to assert, i.e. print some stuff and then call exit. When this happens there is no way to unroll the C stack to get back to the calling python context and notify py.test of the failure. What I have managed to do is intercept the error, and from the intercept use ctypes callback functionality to call into a python handler. It would be nice if I could raise an exception there and use that to get back to the original python context, but ctypes doesn't support that, instead it captures, prints and discards the exception before returning to the C context. I have sent them an idea I have for how the exception could instead optionally be propagated past the C and back to python using setjmp / longjmp, but I'm not really hopeful that that will be a viable alternative. So what I would like to do is clean up py.test in the callback. My ideal outcome would be if I could do some small amount of stuff that would make py.test act as if it were exiting due to a failed test while running with -x. Is this line of approach at all possible? or does it violate the py.test structure too much to be workable? Gordon From holger at merlinux.eu Fri Nov 6 11:53:15 2009 From: holger at merlinux.eu (holger krekel) Date: Fri, 6 Nov 2009 11:53:15 +0100 Subject: [py-dev] unclean shutdown of py.test In-Reply-To: References: Message-ID: <20091106105315.GF29141@trillke.net> Hi Gordon, On Fri, Nov 06, 2009 at 17:11 +1100, Gordon Wrigley wrote: > Short form: > I have a test that in some circumstances can't raise an exception, all > it can do is call stuff. > > Currently it calls sys.exit, which is less than optimal. > Is there a function or series of functions I can call to somewhat > cleanly shutdown py.test in this situation. maybe. > Longer form: > First It is worth noting that we always run py.test with -x, I suspect > that will have some bearing on what follows.. > > The application I'm testing calls a bunch of C code via ctypes. In the > event of certain pathological failures that C code does an internal > error operation equivalent to assert, i.e. print some stuff and then > call exit. > When this happens there is no way to unroll the C stack to get back to > the calling python context and notify py.test of the failure. > What I have managed to do is intercept the error, and from the > intercept use ctypes callback functionality to call into a python > handler. If you have os.fork ... what happens if you run with the "--boxed" option? > It would be nice if I could raise an exception there and use that to > get back to the original python context, ... You can't normally do that with today's Python interpreters. The "--boxed" above looks like the beginning of a clean solution to the problem: Tests are run in a separate process so that reporting is safe from running weirdness. The current --boxed is somewhat limited but it implements this idea. > that, instead it captures, prints and discards the exception before > returning to the C context. > I have sent them an idea I have for how the exception could instead > optionally be propagated past the C and back to python using setjmp / > longjmp, but I'm not really hopeful that that will be a viable > alternative. > So what I would like to do is clean up py.test in the callback. My > ideal outcome would be if I could do some small amount of stuff that > would make py.test act as if it were exiting due to a failed test > while running with -x. > Is this line of approach at all possible? or does it violate the > py.test structure too much to be workable? Actually i'd like to improve on the idea of running tests and reporting about it in separate processes. Btw, the next level of distributed testing i see in the dynamic setup of environments (via virtualenv or buildout) and running tests there, reporting back to console. best, holger From fdg001 at gmx.net Fri Nov 6 11:36:18 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Fri, 06 Nov 2009 10:36:18 +0000 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <20091026111945.GD29141@trillke.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE45A49.70207@gmx.net> <4AE498C5.4000304@gmx.net> <20091026111945.GD29141@trillke.net> Message-ID: <4AF3FC22.2060906@gmx.net> >> http://gist.github.com/214495 > > not sure i see the need for funcargs with this example - > why don't you use the "traditional" setup_module/teardown_module I agree that it seems like overkill. (That's in part intentional though, due to it being a learning experience.) Yet I liked the idea of having a decorator for expressiveness/salience. Also, I was under the impression that {setup,teardown}_{module,class} were deprecated (cf. Philippe's message), with funcargs generally being the preferred option. Since I need setup and teardown for each individual test function, setup_module doesn't help me much - which leaves me with grouping tests into a class. I'm not entirely happy with that though, because it seems a little boilerplatey and potentially makes for weird grouping of tests. This led me to the option of a decorator wrapping the respective test function in a "try: test(); finally: teardown()" - which worked fine, but seemed to obscure the traceback on failures. For my main project, I've realized that I don't actually need teardown. Instead, I use a function call (could perhaps become a decorator) at the _beginning_ of each test which resets the environment (e.g. erasing the data store). This has the added benefit of leaving inspectable leftovers after the last test (handy with py.test -x). I realize this tabula rasa approach might not be suitable for all projects though. -- F. From holger at merlinux.eu Fri Nov 6 12:34:51 2009 From: holger at merlinux.eu (holger krekel) Date: Fri, 6 Nov 2009 12:34:51 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4AF3FC22.2060906@gmx.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE45A49.70207@gmx.net> <4AE498C5.4000304@gmx.net> <20091026111945.GD29141@trillke.net> <4AF3FC22.2060906@gmx.net> Message-ID: <20091106113450.GG29141@trillke.net> Hi Frederik, On Fri, Nov 06, 2009 at 10:36 +0000, Frederik Dohr wrote: > >> http://gist.github.com/214495 > > > > not sure i see the need for funcargs with this example - > > why don't you use the "traditional" setup_module/teardown_module > > I agree that it seems like overkill. (That's in part intentional though, > due to it being a learning experience.) > Yet I liked the idea of having a decorator for expressiveness/salience. > > Also, I was under the impression that {setup,teardown}_{module,class} > were deprecated (cf. Philippe's message), with funcargs generally being > the preferred option. I actually considered deprecation but refrained from it. > Since I need setup and teardown for each individual test function, > setup_module doesn't help me much - which leaves me with grouping tests > into a class. I'm not entirely happy with that though, because it seems > a little boilerplatey and potentially makes for weird grouping of tests. > > This led me to the option of a decorator wrapping the respective test > function in a "try: test(); finally: teardown()" - which worked fine, > but seemed to obscure the traceback on failures. I see. > For my main project, I've realized that I don't actually need teardown. > Instead, I use a function call (could perhaps become a decorator) at the > _beginning_ of each test which resets the environment (e.g. erasing the > data store). This has the added benefit of leaving inspectable leftovers > after the last test (handy with py.test -x). > I realize this tabula rasa approach might not be suitable for all > projects though. In any case it's fine to implement custom testing schemes. For that matter you could automate invocation of a module-level "reset_test_environment" by writing down something like this: #./conftest.py # basically a local project-specific plugin import py def pytest_runtest_setup(item): if not isinstance(item, py.test.collect.Function): return # there are js/doc/other tests modnode = item.getparent(py.test.collect.Module) module = modnode.obj # all python collect nodes have 'obj' reset = hasattr('module', 'reset_test_environment', None) if reset is not None: reset(...) # pass custom parameters You can also pick up per-function parameters which you can set with with a decorator or maybe re-using the improved py.test.mark decorator which already works nicely with Python3. HTH, holger From py-dev at tolomea.com Sun Nov 8 23:45:20 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Mon, 9 Nov 2009 09:45:20 +1100 Subject: [py-dev] unclean shutdown of py.test In-Reply-To: <20091106105315.GF29141@trillke.net> References: <20091106105315.GF29141@trillke.net> Message-ID: > If you have os.fork ... what happens if you run with the "--boxed" option? While py.test seems to come down somewhat cleanly I get no output capturing at all, even with -s? is this expected behavior? I forgot to mention this in the original email but the main reason I want py.test to come down cleanly is so I can get at the captured output. G From py-dev at tolomea.com Mon Nov 9 00:48:51 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Mon, 9 Nov 2009 10:48:51 +1100 Subject: [py-dev] unclean shutdown of py.test In-Reply-To: References: <20091106105315.GF29141@trillke.net> Message-ID: Actually it would probably be more accurate to say that all output is captured. And so I don't see any of my output, both when the test fails and when I run with -s. On Mon, Nov 9, 2009 at 9:45 AM, Gordon Wrigley wrote: >> If you have os.fork ... what happens if you run with the "--boxed" option? > > While py.test seems to come down somewhat cleanly I get no output > capturing at all, even with -s? is this expected behavior? > I forgot to mention this in the original email but the main reason I > want py.test to come down cleanly is so I can get at the captured > output. > > G > From holger at merlinux.eu Mon Nov 9 09:33:53 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 9 Nov 2009 09:33:53 +0100 Subject: [py-dev] unclean shutdown of py.test In-Reply-To: References: <20091106105315.GF29141@trillke.net> Message-ID: <20091109083353.GA29141@trillke.net> Hi Gordon, On Mon, Nov 09, 2009 at 10:48 +1100, Gordon Wrigley wrote: > Actually it would probably be more accurate to say that all output is > captured. And so I don't see any of my output, both when the test > fails and when I run with -s. Ah, do you mean that --boxed and a crashing process does not give you the output? Currently only a completed test will convey back capturing information but i can see that particularly in the crashing case it's interesting to see the output - could you file an issue for that? cheers, holger > > On Mon, Nov 9, 2009 at 9:45 AM, Gordon Wrigley wrote: > >> If you have os.fork ... what happens if you run with the "--boxed" option? > > > > While py.test seems to come down somewhat cleanly I get no output > > capturing at all, even with -s? is this expected behavior? > > I forgot to mention this in the original email but the main reason I > > want py.test to come down cleanly is so I can get at the captured > > output. > > > > G > > > -- From holger at merlinux.eu Tue Nov 10 00:46:31 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 10 Nov 2009 00:46:31 +0100 Subject: [py-dev] uploaded a 1.0.0b3 Message-ID: <20091109234631.GI29141@trillke.net> Hi all, just uploaded a new 1.0.0b3 of execnet. see below for the changelog. cheers, holger 1.0.0b3 -------------------------------- * fix EXECNET_DEBUG to work with win32 * add support for serializing longs, sets and frozensets (thanks Benjamin Peterson) * introduce remote_status() method which on the low level gives information about the remote side of a gateway * disallow explicit close in remote_exec situation * perform some more detailed tracing with EXECNET_DEBUG From phil at freehackers.org Tue Nov 10 14:34:39 2009 From: phil at freehackers.org (Philippe Fremy) Date: Tue, 10 Nov 2009 14:34:39 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <20091104175718.GV29141@trillke.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE459EC.805@gmx.net> <20091026102628.GB29141@trillke.net> <4AE7EE2E.1020208@freehackers.org> <20091104175718.GV29141@trillke.net> Message-ID: <4AF96BEF.4050804@freehackers.org> An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20091110/759aae4c/attachment.htm From holger at merlinux.eu Tue Nov 10 18:52:11 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 10 Nov 2009 18:52:11 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4AF96BEF.4050804@freehackers.org> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE459EC.805@gmx.net> <20091026102628.GB29141@trillke.net> <4AE7EE2E.1020208@freehackers.org> <20091104175718.GV29141@trillke.net> <4AF96BEF.4050804@freehackers.org> Message-ID: <20091110175211.GN29141@trillke.net> Hi Philippe, could you maybe send your mail again as plain text? i had problems interpreting the html version although i probably got the gist of it. thanks, holger On Tue, Nov 10, 2009 at 14:34 +0100, Philippe Fremy wrote: > > > > > > > holger krekel wrote: >
> 
Hi Philippe,
> 
> On Wed, Oct 28, 2009 at 08:09 +0100, Philippe Fremy wrote:
>
>
> 
holger krekel wrote:
>
>
> 
Hi Frederik!
>   
>
>
> 
However, I've finally figured out why I'm having such a hard time  
> warming up to funcargs: They go way beyond the minimalist simplicity  
> that made me switch to py.test in the first place.
> (I realize there's some Magic to py.test's internals, but that doesn't  
> surface in the API.)
> 
> Funcargs seem like a departure from this principle.
> I understand that some situations demand such complexity, so I'm not  
> arguing against funcargs in general - but for my part, I've managed to  
> keep it simple so far.
>     
>
>
>
> 
I second Frederic here. I chose py.test because of the overall
> simplicity of the framework when you use it. The
> setup_module/setup_class/setup_method without any special magic other
> than using function, class or method names starting with test is really
> really nice. I am kind of worried because I could no longer find them in
> the documentation. I eventually found them in the xUnit documentation
> but that's not where I expected them. I vote for a return of this
> documentation to the main py.test documentation, and moving funcarg
> related documentation to an "advanced test setup" section.
>
>
> 

> I am worried that newcomers will be confused then.  But i see
> the point of "unhiding" the xUnit documentation.  
>
>
> You could present the two approaches in the documentation and > explaining what are the differences.
>
> The simplicity of the setup/teardown model is really a strong asset for > testing. It makes the test code architecture understandable by people > not familiar with py.test . The same can not be said for the funcarg > mechanism...
>
>
>
> 
funcarg seems to be a powerful tool, but really cumbersome to grok. I
> find the magic trick on the naming with __myargument a bit cumbersome. I
> would feel more comfortable with a syntax that mimic the setup/teardown
> used for module, class and methods.
>
>
> 

> It would be easy to also allow explicit registration for factories ala:
> 
>     def pytest_configure(config): 
>         config.add_funcarg_factory(name, factoryfunc) 
> 
> but at the time i choose "convention over configuration" and the  
> "__" because Django also uses a similar way to encode values into
> a function name.  
>
>
> I can understand that, but it does not "speak" to people that are not > famliar with this approach. By using this convention, my impression is > that you are leaving behind the people who are just used to functions, > classes and methods.
>
>
>
>
>
> 
This implies having to call magic methods for setting up objects in 
> global namespaces or 'self' attributes - which not only makes the test 
> harder to understand and refactor IMO. 
>
>
> 
I do not agree here. If I have one class with 30 unit test methods, it's
> easier to setup/teardown the test parameters in two methods for the
> whole class than modifying 30 test methods to add funcargs arguments.
>
>
> 

> agreed, i am considering introducing a new hook:
> 
>     def pytest_pyfunc_setup(request):
>         request.cached_setup(setupfunc, teardownfunc, scope="directory")
> 
> and this hook would be called for each python test function.  Here
> we call the cached_setup helper to help us manage setup/teardown scopes. 
> (see http://tinyurl.com/yfw82l5 for request object attributes
> which you could pass into your setup/teardown func)
> 
> It would also mean you could write down:
> 
>     class TestGroup:
>         parameter = 3
>         def test_method(self):
>             assert self.parametrized_obj  ...
> 
> and implement a pytest_pyfunc_setup() to set a "self.someobj" 
> according to the class-specified parameter. 
> 
> Would this make sense to you?  
>
>
> Honestly, I am not sure I get it all.  Can you sketch full examples ?
>
> By the way, is it possible to dynamically update the py.test namespace > ? There is the initial hook py_test_namespace() but it's only called > once. A py.test.update_namespace() would be welcome in my case.
>
>
>
> 
So, while I agree that funcargs certainly has potential, I think you
> should not force it onto the user and should really stress the two ways
> of setting up per class or per method parameters.
>
>
> 

> ok, I'll see to work on the docs a bit. 
>  
>
>
> 
And it would be really nice to figure out a syntax for funcarg that is
> more in the setup/teardown fashion.
> 
> I don't see much gain of using :
> 
> def pytest_funcarg__mysetup(request):
>     return MySetup(request)
> 
> class TestClass:
>     def test_function(self, mysetup):
>         conn = mysetup.getsshconnection()
>         # work with conn
> 
> 
> instead of :
> 
> class TestClass:
>     def setup_class( c ):
>         c.mysetup = MySetup()
> 
>     def test_function(self):
>         conn = c.mysetup.getsshconnection()
>         # work with conn
> 
> 
> The programming style is different, the second one is traditional OO and
> will be familiar to anybody coming from C++, Java or other OO world. The
> second one is playing more on the python capabilities. I don't find it
> more readable.
>
>
> 

> If you have setup_module + setup_class + setup_method (+ subclassing!) 
> layers of setup and teardown, things get a bit harder to understand. 
> In >3000 test projects i know off this led to complexity and 
> refactoring difficulties. 
>
>
> I haven't reached for > 3000 test cases, so I can not comment on > that. But for small projects like the one I am working with (around a > few hundreds tests), the setup/teardown works very well.
>
>
> 
One can argue about the advantage that each test function can take a
> different parameter. While true, in my testing experience, I haven't
> seen a pattern with many different tests taking many different
> parameters. I usually have groups of 5 to 10 tests taking one kind of
> parameter. If they need to take another kind of parameter, I will put
> them in a different test class.
>
>
> 

> These days i sometimes group tests by feature rather than by setup-parameters. 
> E.g. i put two unit-tests and one functional test into a "TestFeature" class. 
>
>
> Then you need a different setup depending on which test you are running > indeed. But you can already do that by discriminating on the method > argument of the setup_method(), no ?
>
>
> 
So, in my opinion, using funcargs for regular cases is a matter of style.
> 
> I do see a big value in funcargs for the parameterized tests. Running
> the same test over and over with different parameter is a really nice
> feature. I think you should stress it more in the documentation.
>
>
> 

> makes sense. thanks a lot for your feedback! 
> 
> best,
> holger
> 
>
>
>
> > > > > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev -- From phil at freehackers.org Tue Nov 10 21:06:23 2009 From: phil at freehackers.org (Philippe Fremy) Date: Tue, 10 Nov 2009 21:06:23 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <20091104175718.GV29141@trillke.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE459EC.805@gmx.net> <20091026102628.GB29141@trillke.net> <4AE7EE2E.1020208@freehackers.org> <20091104175718.GV29141@trillke.net> Message-ID: <4AF9C7BF.1010309@freehackers.org> Hi Holger, Same mail again, this time in plain good old text. Sorry for that, now that I'm using only html for professional email, I tend to forget my good manners for open source projects. holger krekel wrote: > Hi Philippe, > > On Wed, Oct 28, 2009 at 08:09 +0100, Philippe Fremy wrote: > >> holger krekel wrote: >> >>> Hi Frederik! >>> >>> >>>> However, I've finally figured out why I'm having such a hard >>>> time warming up to funcargs: They go way beyond the minimalist >>>> simplicity that made me switch to py.test in the first place. >>>> (I realize there's some Magic to py.test's internals, but that >>>> doesn't surface in the API.) >>>> >>>> Funcargs seem like a departure from this principle. I >>>> understand that some situations demand such complexity, so I'm >>>> not arguing against funcargs in general - but for my part, >>>> I've managed to keep it simple so far. >>>> >>>> >> I second Frederic here. I chose py.test because of the overall >> simplicity of the framework when you use it. The >> setup_module/setup_class/setup_method without any special magic >> other than using function, class or method names starting with test >> is really really nice. I am kind of worried because I could no >> longer find them in the documentation. I eventually found them in >> the xUnit documentation but that's not where I expected them. I >> vote for a return of this documentation to the main py.test >> documentation, and moving funcarg related documentation to an >> "advanced test setup" section. >> > > I am worried that newcomers will be confused then. But i see the > point of "unhiding" the xUnit documentation. > You could present the two approaches in the documentation and explaining what are the differences. The simplicity of the setup/teardown model is really a strong asset for testing. It makes the test code architecture understandable by people not familiar with py.test . The same can not be said for the funcarg mechanism... >> funcarg seems to be a powerful tool, but really cumbersome to grok. >> I find the magic trick on the naming with __myargument a bit >> cumbersome. I would feel more comfortable with a syntax that mimic >> the setup/teardown used for module, class and methods. >> > > It would be easy to also allow explicit registration for factories > ala: > > def pytest_configure(config): config.add_funcarg_factory(name, > factoryfunc) > > but at the time i choose "convention over configuration" and the "__" > because Django also uses a similar way to encode values into a > function name. > I can understand that, but it does not "speak" to people that are not famliar with this approach. By using this convention, my impression is that you are leaving behind the people who are just used to functions, classes and methods. >>> This implies having to call magic methods for setting up objects >>> in global namespaces or 'self' attributes - which not only makes >>> the test harder to understand and refactor IMO. >>> >> I do not agree here. If I have one class with 30 unit test methods, >> it's easier to setup/teardown the test parameters in two methods >> for the whole class than modifying 30 test methods to add funcargs >> arguments. >> > > agreed, i am considering introducing a new hook: > > def pytest_pyfunc_setup(request): request.cached_setup(setupfunc, > teardownfunc, scope="directory") > > and this hook would be called for each python test function. Here we > call the cached_setup helper to help us manage setup/teardown > scopes. (see http://tinyurl.com/yfw82l5 for request object attributes > which you could pass into your setup/teardown func) > > It would also mean you could write down: > > class TestGroup: parameter = 3 def test_method(self): assert > self.parametrized_obj ... > > and implement a pytest_pyfunc_setup() to set a "self.someobj" > according to the class-specified parameter. > > Would this make sense to you? > Honestly, I am not sure I get it all. Can you sketch full examples ? By the way, is it possible to dynamically update the py.test namespace ? There is the initial hook py_test_namespace() but it's only called once. A py.test.update_namespace() would be welcome in my case. >> So, while I agree that funcargs certainly has potential, I think >> you should not force it onto the user and should really stress the >> two ways of setting up per class or per method parameters. >> > > ok, I'll see to work on the docs a bit. > > >> And it would be really nice to figure out a syntax for funcarg that >> is more in the setup/teardown fashion. >> >> I don't see much gain of using : >> >> def pytest_funcarg__mysetup(request): return MySetup(request) >> >> class TestClass: def test_function(self, mysetup): conn = >> mysetup.getsshconnection() # work with conn >> >> >> instead of : >> >> class TestClass: def setup_class( c ): c.mysetup = MySetup() >> >> def test_function(self): conn = c.mysetup.getsshconnection() # work >> with conn >> >> >> The programming style is different, the second one is traditional >> OO and will be familiar to anybody coming from C++, Java or other >> OO world. The second one is playing more on the python >> capabilities. I don't find it more readable. >> > > If you have setup_module + setup_class + setup_method (+ > subclassing!) layers of setup and teardown, things get a bit harder > to understand. In >3000 test projects i know off this led to > complexity and refactoring difficulties. > I haven't reached for > 3000 test cases, so I can not comment on that. But for small projects like the one I am working with (around a few hundreds tests), the setup/teardown works very well. >> One can argue about the advantage that each test function can take >> a different parameter. While true, in my testing experience, I >> haven't seen a pattern with many different tests taking many >> different parameters. I usually have groups of 5 to 10 tests taking >> one kind of parameter. If they need to take another kind of >> parameter, I will put them in a different test class. >> > > These days i sometimes group tests by feature rather than by > setup-parameters. E.g. i put two unit-tests and one functional test > into a "TestFeature" class. > Then you need a different setup depending on which test you are running indeed. But you can already do that by discriminating on the method argument of the setup_method(), no ? >> So, in my opinion, using funcargs for regular cases is a matter of >> style. >> >> I do see a big value in funcargs for the parameterized tests. >> Running the same test over and over with different parameter is a >> really nice feature. I think you should stress it more in the >> documentation. >> > > makes sense. thanks a lot for your feedback! > > best, holger > > From fdg001 at gmx.net Wed Nov 11 13:11:47 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Wed, 11 Nov 2009 12:11:47 +0000 Subject: [py-dev] virtual namespace for plugins Message-ID: <4AFAAA03.7010209@gmx.net> Holger and I had a conversation about virtual namespaces on IRC. We're using this to have a common namespace for plugins*, and Holger expressed interest in using this approach as well. The goal is to use a common package name (here: "foo") for multiple independent modules or packages ("alpha" and "bravo" - to be accessed as foo.alpha and foo.bravo, respectively). It's actually rather simple: The individual components must be contained in a directory named after the virtual namespace, with an __init__.py containing nothing but the following statement: __import__("pkg_resources").declare_namespace(__name__) To make Python aware of the local package (e.g. for running tests out of the repository), something like the following is required in a root-level __init__.py: path = os.path.abspath(VIRTUAL_NAMESPACE) sys.modules[VIRTUAL_NAMESPACE].__dict__["__path__"].insert(0, path) This is illustrated here: http://gist.github.com/231862 Disclaimer: I'm far from being an expert, just sharing what we've learned so far (it's an ongoing effort). -- F. * http://cdent.tumblr.com/post/216241761/python-namespace-packages-for-tiddlyweb From fdg001 at gmx.net Thu Nov 12 19:23:43 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Thu, 12 Nov 2009 18:23:43 +0000 Subject: [py-dev] virtual namespace for plugins In-Reply-To: <4AFAAA03.7010209@gmx.net> References: <4AFAAA03.7010209@gmx.net> Message-ID: <4AFC52AF.3090401@gmx.net> > To make Python aware of the local package (e.g. for running tests out of > the repository), something like the following is required in a > root-level __init__.py: > path = os.path.abspath(VIRTUAL_NAMESPACE) > sys.modules[VIRTUAL_NAMESPACE].__dict__["__path__"].insert(0, path) It appears my testing was flawed; this __init__.py is not being picked up automatically after all (which seemed odd in the first place), at least not by setup.py. So an explicit "import __init__" is required - in which case that module should be renamed, of course. -- F. From holger at merlinux.eu Wed Nov 18 11:53:31 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 18 Nov 2009 11:53:31 +0100 Subject: [py-dev] 1.1.1 wishes, bugs? Message-ID: <20091118105331.GJ17999@trillke.net> Hi, i shortly plan to put out a 1.1.1 fixing some small issues. anything i should look at/consider for the release? If it's small annoyances, just post here, no need to open "issues". best, holger From lac at openend.se Wed Nov 18 14:22:00 2009 From: lac at openend.se (Laura Creighton) Date: Wed, 18 Nov 2009 14:22:00 +0100 Subject: [py-dev] 1.1.1 wishes, bugs? In-Reply-To: Message from holger krekel of "Wed, 18 Nov 2009 11:53:31 +0100." <20091118105331.GJ17999@trillke.net> References: <20091118105331.GJ17999@trillke.net> Message-ID: <200911181322.nAIDM0v6022185@theraft.openend.se> In a message of Wed, 18 Nov 2009 11:53:31 +0100, holger krekel writes: >Hi, > >i shortly plan to put out a 1.1.1 fixing some small issues. >anything i should look at/consider for the release? >If it's small annoyances, just post here, no need >to open "issues". > >best, >holger Small annoyance: Have py.test --help print the message that --report=skipped is how to get more information about skipped tests. Laura From holger at merlinux.eu Tue Nov 24 17:49:50 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 24 Nov 2009 17:49:50 +0100 Subject: [py-dev] execnet-1.0.0 released Message-ID: <20091124164950.GI17999@trillke.net> Hi all, execnet-1.0.0 (compared to 1.0.0b3) has bug fixes, new tested examples and introduces execnet.Group for managing a dynamic bunch of hosts. See the improved docs http://codespeak.net/execnet/ and below the changelog fragment. cheers, holger 1.0.0 compared to 1.0.0b3 -------------------------------- * introduce execnet.Group for managing gateway creation and termination. Introduce execnet.default_group through which all "global" calls are routed. cleanup gateway termination. All Gateways get an id through which they can be retrieved from a group object. * deprecate execnet.XYZGateway in favour of direct makegateway() calls. * refine socketserver-examples, experimentally introduce a way to indirectly setup a socket server ("installvia") through a gateway url. * refine and automatically test documentation examples From holger at merlinux.eu Tue Nov 24 18:12:49 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 24 Nov 2009 18:12:49 +0100 Subject: [py-dev] py.test-1.1.1: compat fixes, setuptools-plugin registration Message-ID: <20091124171249.GK17999@trillke.net> py.test/pylib 1.1.1: bugfix release, setuptools plugin registration -------------------------------------------------------------------------------- This is a compatibility fixing release of pylib/py.test to work better with previous 1.0.x test code bases. It also contains fixes and changes to work with `execnet>=1.0.0`_ to provide distributed testing and looponfailing testing modes. py-1.1.1 moreover introduces a new mechanism for registering plugins via setuptools. What is pylib/py.test? ----------------------- py.test is an advanced automated testing tool working with Python2, Python3 and Jython versions on all major operating systems. It has an extensive plugin architecture and can run many existing common Python test suites without modification. Moreover, it offers some unique features not found in other testing tools. See http://pytest.org for more info. The pylib provides local and svn filesystem Path objects installs some developer-oriented command line tools. See http://pylib.org for more info. thanks to all who helped and gave feedback, have fun, holger (http://twitter.com/hpk42) .. _`execnet>=1.0.0`: http://codespeak.net/execnet Changes between 1.1.1 and 1.1.0 ===================================== - introduce automatic plugin registration via 'pytest11' entrypoints via setuptools' pkg_resources.iter_entry_points - fix py.test dist-testing to work with execnet >= 1.0.0b4 - re-introduce py.test.cmdline.main() for better backward compatibility - svn paths: fix a bug with path.check(versioned=True) for svn paths, allow '%' in svn paths, make svnwc.update() default to interactive mode like in 1.0.x and add svnwc.update(interactive=False) to inhibit interaction. - refine distributed tarball to contain test and no pyc files - try harder to have deprecation warnings for py.compat.* accesses report a correct location From holger at merlinux.eu Sat Nov 28 01:34:08 2009 From: holger at merlinux.eu (holger krekel) Date: Sat, 28 Nov 2009 01:34:08 +0100 Subject: [py-dev] ciss-0.1: code-centered issue tracking Message-ID: <20091128003408.GR29390@trillke.net> Hi all, just released ciss-0.1, my attempt at (what i call) code-centered issue tracking. ciss is: - a command line tool for managing your ISSUES.txt - code-centered: associate issues to files in your project - extensible: assign tags for status/milestone/custom usage. - ueber-powerful issue editing: your text editor! - well tested (more tests than code) If that appeals to you somewhat, check it out: http://codespeak.net/ciss And in case you wonder, why i don't use pitz or ditz? For one, I don't want to edit my issues from an interactive Python prompt, sorry. Second, they create directories and pickle-files and whatnot - i just want to keep a plain text file for a number of projects and using a text editor and a nice cmdline tool is the fastest way i can imagine. Oh, and I do see use in web-based issue interaction but keeping issues close-to-code (tm) and easy-to-edit (tm) is just so much more fun. Besides, i believe 'ciss' could learn to round-trip with existing trackers. anyway, have fun, holger From fdg001 at gmx.net Sat Nov 28 12:33:51 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Sat, 28 Nov 2009 11:33:51 +0000 Subject: [py-dev] ciss-0.1: code-centered issue tracking In-Reply-To: <20091128003408.GR29390@trillke.net> References: <20091128003408.GR29390@trillke.net> Message-ID: <4B110A9F.4050304@gmx.net> > just released ciss-0.1, my attempt at (what i call) > code-centered issue tracking. This certainly looks interesting! (Note: I missed the tutorial link at first, maybe that should be more prominent?) I'm a big proponent of todo.sh (http://todotxt.com), and this fits into the same category - and could even be useful beyond coding. FWIW, todo.sh supports nanoformats like @context and +project (tags and categories, essentially). Perhaps that's worth considering (even though ciss uses multi-line items). > i believe 'ciss' could learn to round-trip with existing trackers That would be most useful. Thanks for sharing! -- F. From holger at merlinux.eu Wed Dec 2 23:36:03 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 2 Dec 2009 23:36:03 +0100 Subject: [py-dev] parametrized tests: need for easy combination? Message-ID: <20091202223603.GK32762@trillke.net> Hi all, Am considering combinations of test test generators currently. Currently if a test like this: def test_function(arg1, arg2): ... has two test generators, one adding calls with multiple values for 'arg1', another for 'arg2' then the code for doing the combinations must be contained in a single test generator, written manually. Now, before i start to think about a backward-compatible way to make this more convenient and allow test generators to orthogonally combine i'd like to know if anybody else felt a similar need. best, holger From Ronny.Pfannschmidt at gmx.de Thu Dec 3 00:30:09 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Thu, 03 Dec 2009 00:30:09 +0100 Subject: [py-dev] parametrized tests: need for easy combination? In-Reply-To: <20091202223603.GK32762@trillke.net> References: <20091202223603.GK32762@trillke.net> Message-ID: <1259796609.25956.24.camel@localhost> On Wed, 2009-12-02 at 23:36 +0100, holger krekel wrote: > Hi all, > > Am considering combinations of test test generators currently. > Currently if a test like this: > > def test_function(arg1, arg2): > ... > > has two test generators, one adding calls > with multiple values for 'arg1', another > for 'arg2' then the code for doing the > combinations must be contained in a single > test generator, written manually. > > Now, before i start to think about a backward-compatible > way to make this more convenient and allow test generators > to orthogonally combine i'd like to know if anybody > else felt a similar need. I feelt that need. In anyvc i have a set of tests where i need/want to run a set of remote backends on a set of python versions. However currently i'm under the impression that the new proposed dist-model might already do (im not sure on that yet). Still i'd like to propose some of my toughts on a hopefuly backward-compatible extension to the current test-generator model. I think the basic need is to chain and/or nest these generators. i.e. find all declarations that apply, figure an order, then proceed to call the 'inner' hook for each addcall invocation in an 'outer' hook 'inner' hooks are simply ordered after 'outer' hooks in the list of fitting hooks now, that would work well for hooks from plugins, or packages/modules, however it doesnt yet work well for defining 2 different hooks at the same level. one could use something like a tuple, or a dedicated object in order to manage n hooks at a time. other options would include smart decorators or prefixes. As more than one hook at a level is generally tricky to get right&nice its something that requires a good deal of discussion if combinatoric versions of the generate_test hooks are considered for implementation. Regards Ronny From holger at merlinux.eu Sat Dec 5 19:41:34 2009 From: holger at merlinux.eu (holger krekel) Date: Sat, 5 Dec 2009 19:41:34 +0100 Subject: [py-dev] execnet-1.0.1: more robust and rapid python deployment Message-ID: <20091205184134.GA19640@trillke.net> Hi everybody, Just uploaded execnet-1.0.1 featuring a new motto: execnet is about rapid-python deployment, be it for multiple CPUs, different platforms or python versions. This release brings a bunch of refinements and most importantly more robust termination, handling of CTRL-C and automatically tested documentation:: http://codespeak.net/execnet have fun, holger 1.0.1 -------------------------------- - revamp and better structure documentation - new method: gateway.hasreceiver() returns True if the gateway is still receive-active. remote_status now only carries information about remote execution status. - new: execnet.MultiChannel provides basic iteration/contain interface - new: execnet.Group can be indexed by integer - new: group.makegateway() uses group.default_spec if no spec is given and the execnet.default_group uses ``popen`` as a default spec. - have popen-gateways use imports instead of source-strings, also improves debugging/tracebacks, as a side effect popen-gateway startup can be substantially faster (>30%) - refine internal gateway exit/termination procedure and introduce group.terminate(timeout) which will attempt to kill all subprocesses that did not terminate within time. - EOFError on channel.receive/waitclose if the other side unexpectedly went away. When a gateway exits it now internally sends an explicit termination message instead of abruptly closing. - introduce a timeout parameter to channel.receive() and default to periodically internally wake up to let KeyboardInterrupts pass through. - EXECNET_DEBUG=2 will cause tracing to go to stderr, which with popen slave gateways will relay back tracing to the instantiator process. 1.0.0 -------------------------------- * introduce execnet.Group for managing gateway creation and termination. Introduce execnet.default_group through which all "global" calls are routed. cleanup gateway termination. All Gateways get an id through which they can be retrieved from a group object. * deprecate execnet.XYZGateway in favour of direct makegateway() calls. * refine socketserver-examples, experimentally introduce a way to indirectly setup a socket server ("installvia") through a gateway url. * refine and automatically test documentation examples 1.0.0b3 -------------------------------- * fix EXECNET_DEBUG to work with win32 * add support for serializing longs, sets and frozensets (thanks Benjamin Peterson) * introduce remote_status() method which on the low level gives information about the remote side of a gateway * disallow explicit close in remote_exec situation * perform some more detailed tracing with EXECNET_DEBUG 1.0.0b2 -------------------------------- * make internal protocols more robust against serialization failures * fix a seralization bug with nested tuples containing empty tuples (thanks to ronny for discovering it) * setting the environment variable EXECNET_DEBUG will generate per process trace-files for debugging 1.0.0b1 ---------------------------- * added new examples for NumPy, Jython, IronPython * improved documentation * include apipkg.py for lazy-importing * integrated new serializer code from Benjamin Peterson * improved support for Jython-2.5.1 1.0.0alpha2 ---------------------------- * improve documentation, new website * use sphinx for documentation, added boilerplate files and setup.py * fixes for standalone usage, adding boilerplate files * imported py/execnet and made it work standalone ----- End forwarded message ----- -- From fijall at gmail.com Tue Dec 8 11:12:15 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 8 Dec 2009 11:12:15 +0100 Subject: [py-dev] broken link Message-ID: <693bc9ab0912080212v2f8de524m648d37cab119d53a@mail.gmail.com> http://bitbucket.org/hpk42/py-trunk/src/tip/py/test/plugin/pytest_pdb.py is a broken link from http://codespeak.net/py/dist/test/customize.html From holger at merlinux.eu Fri Dec 11 14:19:46 2009 From: holger at merlinux.eu (holger krekel) Date: Fri, 11 Dec 2009 14:19:46 +0100 Subject: [py-dev] broken link In-Reply-To: <693bc9ab0912080212v2f8de524m648d37cab119d53a@mail.gmail.com> References: <693bc9ab0912080212v2f8de524m648d37cab119d53a@mail.gmail.com> Message-ID: <20091211131946.GF3516@trillke.net> On Tue, Dec 08, 2009 at 11:12 +0100, Maciej Fijalkowski wrote: > http://bitbucket.org/hpk42/py-trunk/src/tip/py/test/plugin/pytest_pdb.py > > is a broken link from > > http://codespeak.net/py/dist/test/customize.html thanks, fixed. keep such or other doc-issues coming! :) holger From schmir at gmail.com Wed Dec 16 10:47:54 2009 From: schmir at gmail.com (schmir at gmail.com) Date: Wed, 16 Dec 2009 10:47:54 +0100 Subject: [py-dev] AttributeError: 'module' object has no attribute 'suite' Message-ID: <87iqc7cks5.fsf@muni.brainbot.com> got the following error while running our tests. py 1.0.0 works for us: [py26] [git:master] ~/rl/ % py.test ============================================================================================= test session starts ============================================================================================= python: platform linux2 -- Python 2.6.4 -- pytest-1.1.1 test object 1: /home/test/rl Traceback (most recent call last): File "/home/test/py26/bin/py.test", line 9, in load_entry_point('py==1.1.1', 'console_scripts', 'py.test')() File "/home/test/py26/lib/python2.6/site-packages/py/impl/test/cmdline.py", line 16, in main exitstatus = session.main() File "/home/test/py26/lib/python2.6/site-packages/py/impl/test/session.py", line 121, in main self.config.pluginmanager.notify_exception(captured_excinfo) File "/home/test/py26/lib/python2.6/site-packages/py/impl/test/pluginmanager.py", line 184, in notify_exception excrepr = excinfo.getrepr(funcargs=True, showlocals=True) File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 413, in getrepr return fmt.repr_excinfo(self) File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 574, in repr_excinfo reprtraceback = self.repr_traceback(excinfo) File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 566, in repr_traceback reprentry = self.repr_traceback_entry(entry, einfo) File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 521, in repr_traceback_entry source = self._getentrysource(entry) File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 449, in _getentrysource source = entry.getsource() File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 221, in getsource _, end = source.getstatementrange(end) File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/source.py", line 131, in getstatementrange if trysource.isparseable(): File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/source.py", line 165, in isparseable syntax_checker = parser.suite AttributeError: 'module' object has no attribute 'suite' Any ideas? From holger at merlinux.eu Thu Dec 17 09:24:42 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 17 Dec 2009 09:24:42 +0100 Subject: [py-dev] AttributeError: 'module' object has no attribute 'suite' In-Reply-To: <87iqc7cks5.fsf@muni.brainbot.com> References: <87iqc7cks5.fsf@muni.brainbot.com> Message-ID: <20091217082442.GH3516@trillke.net> It's odd that py-1.0 works and 1.1 doesn't but could it be that you have a "parser" module of your own or somehow in the import path? holger On Wed, Dec 16, 2009 at 10:47 +0100, schmir at gmail.com wrote: > got the following error while running our tests. py 1.0.0 works for us: > > [py26] [git:master] ~/rl/ % py.test > ============================================================================================= test session starts ============================================================================================= > python: platform linux2 -- Python 2.6.4 -- pytest-1.1.1 > test object 1: /home/test/rl > Traceback (most recent call last): > File "/home/test/py26/bin/py.test", line 9, in > load_entry_point('py==1.1.1', 'console_scripts', 'py.test')() > File "/home/test/py26/lib/python2.6/site-packages/py/impl/test/cmdline.py", line 16, in main > exitstatus = session.main() > File "/home/test/py26/lib/python2.6/site-packages/py/impl/test/session.py", line 121, in main > self.config.pluginmanager.notify_exception(captured_excinfo) > File "/home/test/py26/lib/python2.6/site-packages/py/impl/test/pluginmanager.py", line 184, in notify_exception > excrepr = excinfo.getrepr(funcargs=True, showlocals=True) > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 413, in getrepr > return fmt.repr_excinfo(self) > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 574, in repr_excinfo > reprtraceback = self.repr_traceback(excinfo) > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 566, in repr_traceback > reprentry = self.repr_traceback_entry(entry, einfo) > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 521, in repr_traceback_entry > source = self._getentrysource(entry) > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 449, in _getentrysource > source = entry.getsource() > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 221, in getsource > _, end = source.getstatementrange(end) > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/source.py", line 131, in getstatementrange > if trysource.isparseable(): > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/source.py", line 165, in isparseable > syntax_checker = parser.suite > AttributeError: 'module' object has no attribute 'suite' > > Any ideas? > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From holger at merlinux.eu Thu Dec 17 09:37:49 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 17 Dec 2009 09:37:49 +0100 Subject: [py-dev] AttributeError: 'module' object has no attribute 'suite' In-Reply-To: <20091217082442.GH3516@trillke.net> References: <87iqc7cks5.fsf@muni.brainbot.com> <20091217082442.GH3516@trillke.net> Message-ID: <20091217083749.GI3516@trillke.net> On Thu, Dec 17, 2009 at 09:24 +0100, holger krekel wrote: > It's odd that py-1.0 works and 1.1 doesn't but could it be > that you have a "parser" module of your own or somehow > in the import path? no oddity, actually. py-1.1 uses the standard 'parser' module where py-1.0 used the standard compiler package to check for parseability. So it's probably right that you have a 'parser' module shadowing the standard one. holger to re-interpretet assert expressions which ion not odd, actually > holger > > On Wed, Dec 16, 2009 at 10:47 +0100, schmir at gmail.com wrote: > > got the following error while running our tests. py 1.0.0 works for us: > > > > [py26] [git:master] ~/rl/ % py.test > > ============================================================================================= test session starts ============================================================================================= > > python: platform linux2 -- Python 2.6.4 -- pytest-1.1.1 > > test object 1: /home/test/rl > > Traceback (most recent call last): > > File "/home/test/py26/bin/py.test", line 9, in > > load_entry_point('py==1.1.1', 'console_scripts', 'py.test')() > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/test/cmdline.py", line 16, in main > > exitstatus = session.main() > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/test/session.py", line 121, in main > > self.config.pluginmanager.notify_exception(captured_excinfo) > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/test/pluginmanager.py", line 184, in notify_exception > > excrepr = excinfo.getrepr(funcargs=True, showlocals=True) > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 413, in getrepr > > return fmt.repr_excinfo(self) > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 574, in repr_excinfo > > reprtraceback = self.repr_traceback(excinfo) > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 566, in repr_traceback > > reprentry = self.repr_traceback_entry(entry, einfo) > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 521, in repr_traceback_entry > > source = self._getentrysource(entry) > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 449, in _getentrysource > > source = entry.getsource() > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/code.py", line 221, in getsource > > _, end = source.getstatementrange(end) > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/source.py", line 131, in getstatementrange > > if trysource.isparseable(): > > File "/home/test/py26/lib/python2.6/site-packages/py/impl/code/source.py", line 165, in isparseable > > syntax_checker = parser.suite > > AttributeError: 'module' object has no attribute 'suite' > > > > Any ideas? > > _______________________________________________ > > 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 schmir at gmail.com Thu Dec 17 11:57:00 2009 From: schmir at gmail.com (schmir at gmail.com) Date: Thu, 17 Dec 2009 11:57:00 +0100 Subject: [py-dev] AttributeError: 'module' object has no attribute 'suite' In-Reply-To: <20091217083749.GI3516@trillke.net> (holger krekel's message of "Thu, 17 Dec 2009 09:37:49 +0100") References: <87iqc7cks5.fsf@muni.brainbot.com> <20091217082442.GH3516@trillke.net> <20091217083749.GI3516@trillke.net> Message-ID: <87iqc57ts3.fsf@muni.brainbot.com> holger krekel writes: > > no oddity, actually. py-1.1 uses the standard 'parser' > module where py-1.0 used the standard compiler package > to check for parseability. So it's probably right > that you have a 'parser' module shadowing the standard > one. you're right. Adding some print statements I can see that it uses /home/test/py26/lib/python2.6/site-packages/mwlib/parser/__init__.pyc as it's parser module. sys.path looks like ['/home/test/py26/lib/python2.6/site-packages/mwlib', '/home/test/rl', '/home/test/py26/lib/python2.6/site-packages', '/home/test/py26/bin', '/home/test/py26/lib/python2.6/site-packages/distribute-0.6.8-py2.6.egg', ...] in that function. The first entry looks wrong here. mwlib is a standard namespace package and .../site-packages/mwlib should not be in sys.path. (and it's really not there in the standard interpreter). Regards, - Ralf From schmir at gmail.com Thu Dec 17 23:46:01 2009 From: schmir at gmail.com (schmir at gmail.com) Date: Thu, 17 Dec 2009 22:46:01 +0000 Subject: [py-dev] AttributeError: 'module' object has no attribute 'suite' In-Reply-To: <87iqc57ts3.fsf@muni.brainbot.com> (schmir@gmail.com's message of "Thu, 17 Dec 2009 11:57:00 +0100") References: <87iqc7cks5.fsf@muni.brainbot.com> <20091217082442.GH3516@trillke.net> <20091217083749.GI3516@trillke.net> <87iqc57ts3.fsf@muni.brainbot.com> Message-ID: <87oclx9q3a.fsf@brainbot.com> schmir at gmail.com writes: > holger krekel writes: > >> >> no oddity, actually. py-1.1 uses the standard 'parser' >> module where py-1.0 used the standard compiler package >> to check for parseability. So it's probably right >> that you have a 'parser' module shadowing the standard >> one. > > you're right. Adding some print statements I can see that it uses > this has nothing to do with the py lib. sorry for the noise and thanks for your help. regards, - ralf From holger at merlinux.eu Sun Dec 20 22:48:52 2009 From: holger at merlinux.eu (holger krekel) Date: Sun, 20 Dec 2009 22:48:52 +0100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... Message-ID: <20091220214852.GB3516@trillke.net> Hi all, i just committed a change which i'd release together with a bunch of other things as py-1.1.2. It makes py.test install as py.test # if python executable has basename 'python' py.test3 # if python executable has version_info >= (3,0) py.test2.x # if python executable has basename 'python2.x' (x in '4567') py.test-jython # if we are running on jython2.5 py.test-pypy # if we are running on pypy does this make sense to you, objections? It does for me because i can more easily run tests with various interpreters. But it means if you run "python2.4 setup.py install" you will not get a 'py.test2.4' only, and no 'py.test' proper. cheers, holger From lac at openend.se Sun Dec 20 22:56:57 2009 From: lac at openend.se (Laura Creighton) Date: Sun, 20 Dec 2009 22:56:57 +0100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: Message from holger krekel of "Sun, 20 Dec 2009 22:48:52 +0100." <20091220214852.GB3516@trillke.net> References: <20091220214852.GB3516@trillke.net> Message-ID: <200912202156.nBKLuvXU002692@theraft.openend.se> In a message of Sun, 20 Dec 2009 22:48:52 +0100, holger krekel writes: >Hi all, > >i just committed a change which i'd release together with a bunch >of other things as py-1.1.2. It makes py.test install as > > py.test # if python executable has basename 'python' > py.test3 # if python executable has version_info >= (3,0) > py.test2.x # if python executable has basename 'python2.x' (x in >'4567') > py.test-jython # if we are running on jython2.5 > py.test-pypy # if we are running on pypy > >does this make sense to you, objections? It does for me because >i can more easily run tests with various interpreters. But >it means if you run "python2.4 setup.py install" you will not >get a 'py.test2.4' only, and no 'py.test' proper. > >cheers, >holger Ah, you mean you _will_ only get a py.text2.4 ?? or ... Laura From holger at merlinux.eu Sun Dec 20 23:00:34 2009 From: holger at merlinux.eu (holger krekel) Date: Sun, 20 Dec 2009 23:00:34 +0100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: <200912202156.nBKLuvXU002692@theraft.openend.se> References: <20091220214852.GB3516@trillke.net> <200912202156.nBKLuvXU002692@theraft.openend.se> Message-ID: <20091220220034.GC3516@trillke.net> On Sun, Dec 20, 2009 at 22:56 +0100, Laura Creighton wrote: > In a message of Sun, 20 Dec 2009 22:48:52 +0100, holger krekel writes: > >Hi all, > > > >i just committed a change which i'd release together with a bunch > >of other things as py-1.1.2. It makes py.test install as > > > > py.test # if python executable has basename 'python' > > py.test3 # if python executable has version_info >= (3,0) > > py.test2.x # if python executable has basename 'python2.x' (x in > >'4567') > > py.test-jython # if we are running on jython2.5 > > py.test-pypy # if we are running on pypy > > > >does this make sense to you, objections? It does for me because > >i can more easily run tests with various interpreters. But > >it means if you run "python2.4 setup.py install" you will not > >get a 'py.test2.4' only, and no 'py.test' proper. > > > >cheers, > >holger > > Ah, you mean you _will_ only get a py.text2.4 ?? or ... yes, currently it would be 'py.test2.4' only if the executable is named "python2.4". If it's named "python" and has version_info==(2,4,..) it would still install as 'py.test'. holger From py-dev at tolomea.com Sun Dec 20 23:05:10 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Mon, 21 Dec 2009 09:05:10 +1100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: <20091220220034.GC3516@trillke.net> References: <20091220214852.GB3516@trillke.net> <200912202156.nBKLuvXU002692@theraft.openend.se> <20091220220034.GC3516@trillke.net> Message-ID: Holger, So I currently have python, python2, python2.5 and python2.6 available on my machine. 2.5 and 2.6 are actual executables, the other two are symlinks to python2.6. What py.test executables will I get? My preference would be for it to mirror the python ones. I don't care about python2 so much, but having it mirror the other 3 would be good. Gordon On Mon, Dec 21, 2009 at 9:00 AM, holger krekel wrote: > On Sun, Dec 20, 2009 at 22:56 +0100, Laura Creighton wrote: >> In a message of Sun, 20 Dec 2009 22:48:52 +0100, holger krekel writes: >> >Hi all, >> > >> >i just committed a change which i'd release together with a bunch >> >of other things as py-1.1.2. ?It makes py.test install as >> > >> > ? ?py.test ? ? ? ?# if python executable has basename 'python' >> > ? ?py.test3 ? ? ? # if python executable has version_info >= (3,0) >> > ? ?py.test2.x ? ? # if python executable has basename 'python2.x' (x in >> >'4567') >> > ? ?py.test-jython # if we are running on jython2.5 >> > ? ?py.test-pypy ? # if we are running on pypy >> > >> >does this make sense to you, objections? ?It does for me because >> >i can more easily run tests with various interpreters. ?But >> >it means if you run "python2.4 setup.py install" you will not >> >get a 'py.test2.4' only, and no 'py.test' proper. >> > >> >cheers, >> >holger >> >> Ah, you mean you _will_ only get a py.text2.4 ?? or ... > > yes, currently it would be 'py.test2.4' only if the executable is > named "python2.4". ?If it's named "python" and has version_info==(2,4,..) > it would still install as 'py.test'. > > holger > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > From lac at openend.se Sun Dec 20 23:12:36 2009 From: lac at openend.se (Laura Creighton) Date: Sun, 20 Dec 2009 23:12:36 +0100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: Message from holger krekel of "Sun, 20 Dec 2009 23:00:34 +0100." <20091220220034.GC3516@trillke.net> References: <20091220214852.GB3516@trillke.net> <200912202156.nBKLuvXU002692@theraft.openend.se> <20091220220034.GC3516@trillke.net> Message-ID: <200912202212.nBKMCa7L003864@theraft.openend.se> In a message of Sun, 20 Dec 2009 23:00:34 +0100, holger krekel writes: >yes, currently it would be 'py.test2.4' only if the executable is >named "python2.4". If it's named "python" and has version_info==(2,4,..) >it would still install as 'py.test'. > >holger Thank you for clarifying, and, yes I don't have a problem with this. Laura From holger at merlinux.eu Sun Dec 20 23:22:14 2009 From: holger at merlinux.eu (holger krekel) Date: Sun, 20 Dec 2009 23:22:14 +0100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: References: <20091220214852.GB3516@trillke.net> <200912202156.nBKLuvXU002692@theraft.openend.se> <20091220220034.GC3516@trillke.net> Message-ID: <20091220222214.GD3516@trillke.net> Hi Gordon, On Mon, Dec 21, 2009 at 09:05 +1100, Gordon Wrigley wrote: > Holger, > > So I currently have python, python2, python2.5 and python2.6 available > on my machine. 2.5 and 2.6 are actual executables, the other two are > symlinks to python2.6. > > What py.test executables will I get? python setup.py install -> py.test python2 setup.py install -> py.test2 python2.5 setup.py install -> py.test2.5 python2.6 setup.py install -> py.test2.6 > My preference would be for it to mirror the python ones. I don't care > about python2 so much, but having it mirror the other 3 would be good. seems to match. Maybe i also additionally always do a "py.test" proper so that people using the current way are not surprised. That would mirror how 'easy_install' is installed (it has a '-' dash in the middle though which i find suboptimal tab-completion-wise) On Windows it looks slightly different at the moment because there are usually no "pythonXYZ" differentiations but only different c:\\PythonXYZ\Python.exe files. As there is no common "bin" dir i guess using "py.test" always there is kind of fine?! holger > > Gordon > > On Mon, Dec 21, 2009 at 9:00 AM, holger krekel wrote: > > On Sun, Dec 20, 2009 at 22:56 +0100, Laura Creighton wrote: > >> In a message of Sun, 20 Dec 2009 22:48:52 +0100, holger krekel writes: > >> >Hi all, > >> > > >> >i just committed a change which i'd release together with a bunch > >> >of other things as py-1.1.2. ?It makes py.test install as > >> > > >> > ? ?py.test ? ? ? ?# if python executable has basename 'python' > >> > ? ?py.test3 ? ? ? # if python executable has version_info >= (3,0) > >> > ? ?py.test2.x ? ? # if python executable has basename 'python2.x' (x in > >> >'4567') > >> > ? ?py.test-jython # if we are running on jython2.5 > >> > ? ?py.test-pypy ? # if we are running on pypy > >> > > >> >does this make sense to you, objections? ?It does for me because > >> >i can more easily run tests with various interpreters. ?But > >> >it means if you run "python2.4 setup.py install" you will not > >> >get a 'py.test2.4' only, and no 'py.test' proper. > >> > > >> >cheers, > >> >holger > >> > >> Ah, you mean you _will_ only get a py.text2.4 ?? or ... > > > > yes, currently it would be 'py.test2.4' only if the executable is > > named "python2.4". ?If it's named "python" and has version_info==(2,4,..) > > it would still install as 'py.test'. > > > > 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 py-dev at tolomea.com Sun Dec 20 23:30:17 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Mon, 21 Dec 2009 09:30:17 +1100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: <20091220222214.GD3516@trillke.net> References: <20091220214852.GB3516@trillke.net> <200912202156.nBKLuvXU002692@theraft.openend.se> <20091220220034.GC3516@trillke.net> <20091220222214.GD3516@trillke.net> Message-ID: Hi Holger, Ok, that makes sense, however we always use easy_install, currently I have easy_install, easy_install-2.5 and easy_install-2.6. Will this work the same as with setup.py? Gordon On Mon, Dec 21, 2009 at 9:22 AM, holger krekel wrote: > Hi Gordon, > > On Mon, Dec 21, 2009 at 09:05 +1100, Gordon Wrigley wrote: >> Holger, >> >> So I currently have python, python2, python2.5 and python2.6 available >> on my machine. 2.5 and 2.6 are actual executables, the other two are >> symlinks to python2.6. >> >> What py.test executables will I get? > > python setup.py install ? ?-> py.test > python2 setup.py install ? -> py.test2 > python2.5 setup.py install -> py.test2.5 > python2.6 setup.py install -> py.test2.6 > >> My preference would be for it to mirror the python ones. I don't care >> about python2 so much, but having it mirror the other 3 would be good. > > seems to match. ?Maybe i also additionally always do a "py.test" proper > so that people using the current way are not surprised. ? That would mirror > how 'easy_install' is installed (it has a '-' dash in the middle though which > i find suboptimal tab-completion-wise) > > On Windows it looks slightly different at the moment because there are usually > no "pythonXYZ" differentiations but only different c:\\PythonXYZ\Python.exe files. > As there is no common "bin" dir i guess using "py.test" always there is kind of > fine?! > > holger > >> >> Gordon >> >> On Mon, Dec 21, 2009 at 9:00 AM, holger krekel wrote: >> > On Sun, Dec 20, 2009 at 22:56 +0100, Laura Creighton wrote: >> >> In a message of Sun, 20 Dec 2009 22:48:52 +0100, holger krekel writes: >> >> >Hi all, >> >> > >> >> >i just committed a change which i'd release together with a bunch >> >> >of other things as py-1.1.2. ?It makes py.test install as >> >> > >> >> > ? ?py.test ? ? ? ?# if python executable has basename 'python' >> >> > ? ?py.test3 ? ? ? # if python executable has version_info >= (3,0) >> >> > ? ?py.test2.x ? ? # if python executable has basename 'python2.x' (x in >> >> >'4567') >> >> > ? ?py.test-jython # if we are running on jython2.5 >> >> > ? ?py.test-pypy ? # if we are running on pypy >> >> > >> >> >does this make sense to you, objections? ?It does for me because >> >> >i can more easily run tests with various interpreters. ?But >> >> >it means if you run "python2.4 setup.py install" you will not >> >> >get a 'py.test2.4' only, and no 'py.test' proper. >> >> > >> >> >cheers, >> >> >holger >> >> >> >> Ah, you mean you _will_ only get a py.text2.4 ?? or ... >> > >> > yes, currently it would be 'py.test2.4' only if the executable is >> > named "python2.4". ?If it's named "python" and has version_info==(2,4,..) >> > it would still install as 'py.test'. >> > >> > 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 Sun Dec 20 23:35:33 2009 From: holger at merlinux.eu (holger krekel) Date: Sun, 20 Dec 2009 23:35:33 +0100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: References: <20091220214852.GB3516@trillke.net> <200912202156.nBKLuvXU002692@theraft.openend.se> <20091220220034.GC3516@trillke.net> <20091220222214.GD3516@trillke.net> Message-ID: <20091220223533.GE3516@trillke.net> On Mon, Dec 21, 2009 at 09:30 +1100, Gordon Wrigley wrote: > Hi Holger, > > Ok, that makes sense, however we always use easy_install, currently I > have easy_install, easy_install-2.5 and easy_install-2.6. Will this > work the same as with setup.py? easy_install-2.5 and easy_install-2.6 should give py.test2.5 and py.test2.6. For 'easy_install' proper it depends on which python executable it uses. Unless we always install 'py.test' in all cases in which case the last install wins and gets 'py.test'. holger > Gordon > > On Mon, Dec 21, 2009 at 9:22 AM, holger krekel wrote: > > Hi Gordon, > > > > On Mon, Dec 21, 2009 at 09:05 +1100, Gordon Wrigley wrote: > >> Holger, > >> > >> So I currently have python, python2, python2.5 and python2.6 available > >> on my machine. 2.5 and 2.6 are actual executables, the other two are > >> symlinks to python2.6. > >> > >> What py.test executables will I get? > > > > python setup.py install ? ?-> py.test > > python2 setup.py install ? -> py.test2 > > python2.5 setup.py install -> py.test2.5 > > python2.6 setup.py install -> py.test2.6 > > > >> My preference would be for it to mirror the python ones. I don't care > >> about python2 so much, but having it mirror the other 3 would be good. > > > > seems to match. ?Maybe i also additionally always do a "py.test" proper > > so that people using the current way are not surprised. ? That would mirror > > how 'easy_install' is installed (it has a '-' dash in the middle though which > > i find suboptimal tab-completion-wise) > > > > On Windows it looks slightly different at the moment because there are usually > > no "pythonXYZ" differentiations but only different c:\\PythonXYZ\Python.exe files. > > As there is no common "bin" dir i guess using "py.test" always there is kind of > > fine?! > > > > holger > > > >> > >> Gordon > >> > >> On Mon, Dec 21, 2009 at 9:00 AM, holger krekel wrote: > >> > On Sun, Dec 20, 2009 at 22:56 +0100, Laura Creighton wrote: > >> >> In a message of Sun, 20 Dec 2009 22:48:52 +0100, holger krekel writes: > >> >> >Hi all, > >> >> > > >> >> >i just committed a change which i'd release together with a bunch > >> >> >of other things as py-1.1.2. ?It makes py.test install as > >> >> > > >> >> > ? ?py.test ? ? ? ?# if python executable has basename 'python' > >> >> > ? ?py.test3 ? ? ? # if python executable has version_info >= (3,0) > >> >> > ? ?py.test2.x ? ? # if python executable has basename 'python2.x' (x in > >> >> >'4567') > >> >> > ? ?py.test-jython # if we are running on jython2.5 > >> >> > ? ?py.test-pypy ? # if we are running on pypy > >> >> > > >> >> >does this make sense to you, objections? ?It does for me because > >> >> >i can more easily run tests with various interpreters. ?But > >> >> >it means if you run "python2.4 setup.py install" you will not > >> >> >get a 'py.test2.4' only, and no 'py.test' proper. > >> >> > > >> >> >cheers, > >> >> >holger > >> >> > >> >> Ah, you mean you _will_ only get a py.text2.4 ?? or ... > >> > > >> > yes, currently it would be 'py.test2.4' only if the executable is > >> > named "python2.4". ?If it's named "python" and has version_info==(2,4,..) > >> > it would still install as 'py.test'. > >> > > >> > 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 Adam.Schmalhofer at gmx.de Mon Dec 21 10:11:58 2009 From: Adam.Schmalhofer at gmx.de (Adam) Date: Mon, 21 Dec 2009 10:11:58 +0100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: <20091220214852.GB3516@trillke.net> References: <20091220214852.GB3516@trillke.net> Message-ID: <20091221101158.7af1750a@deepthought.fritz.box> holger krekel wrote: > It makes py.test install as > > py.test # if python executable has basename 'python' > py.test3 # if python executable has version_info >= (3,0) > py.test2.x # if python executable has basename 'python2.x' (x in > '4567') py.test-jython # if we are running on jython2.5 > py.test-pypy # if we are running on pypy > > does this make sense to you, objections? I don't know how easy it will be to get this to work with debian's python-setup (or for any other distributor). > It does for me because > i can more easily run tests with various interpreters. I think it is rather limited. If I want to know if my program has interpreter dependant bugs I have to run all of the py.tests and compare the outputs manually. What is the advantage of "py.test3" over running "py.test --tx popen//python3"? Maybe instead add a shortcut for the "--tx popen"s? Like "py.test -i3,2.4,j,pypy" to run the tests with many different interpreters one after each other. --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/20091221/55ed4927/attachment.pgp From holger at merlinux.eu Mon Dec 21 11:01:17 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 21 Dec 2009 11:01:17 +0100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: <20091221101158.7af1750a@deepthought.fritz.box> References: <20091220214852.GB3516@trillke.net> <20091221101158.7af1750a@deepthought.fritz.box> Message-ID: <20091221100117.GH3516@trillke.net> On Mon, Dec 21, 2009 at 10:11 +0100, Adam wrote: > holger krekel wrote: > > > It makes py.test install as > > > > py.test # if python executable has basename 'python' > > py.test3 # if python executable has version_info >= (3,0) > > py.test2.x # if python executable has basename 'python2.x' (x in > > '4567') py.test-jython # if we are running on jython2.5 > > py.test-pypy # if we are running on pypy > > > > does this make sense to you, objections? > > I don't know how easy it will be to get this to work with > debian's python-setup (or for any other distributor). good point. OTOH they anyway modify the setup.py anyway so it's easy to implement their policy. I believe python3 is currently the standard so they probably should do 'py.test3' at least ... (not sure who is doing py.test debian packaging currently, btw) > > It does for me because > > i can more easily run tests with various interpreters. > > I think it is rather limited. If I want to know if my program has > interpreter dependant bugs I have to run all of the py.tests and compare > the outputs manually. > > What is the advantage of "py.test3" over running "py.test --tx > popen//python3"? ... it wouldn't work as py.test cannot currently do dist-testing across python2/python3 barriers ... > Maybe instead add a shortcut for the "--tx popen"s? > > Like "py.test -i3,2.4,j,pypy" to run the tests with many different > interpreters one after each other. I agree that this is the way to go. py.test's current dist-testing model has some limitations which can partially get in the way. Most notably it is the invoking python interpreter context that determines which tests are collected and distributed - e.g. test modules that produce a skip during import would never get send to ther other side. The other bit is that it might not be easy to discover all interpreters automatically. That being said, i am considering to actually follow your suggestion and implement the '-i' option. And also provide a py.test3 for python3. If you specify interpreters that don't exist what would you like py.test to do? Bail out up-front or produce skips or ..? cheers & thanks, holger From Adam.Schmalhofer at gmx.de Mon Dec 21 16:16:35 2009 From: Adam.Schmalhofer at gmx.de (Adam) Date: Mon, 21 Dec 2009 16:16:35 +0100 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: <20091221100117.GH3516@trillke.net> References: <20091220214852.GB3516@trillke.net> <20091221101158.7af1750a@deepthought.fritz.box> <20091221100117.GH3516@trillke.net> Message-ID: <20091221161635.6a4013fe@deepthought.fritz.box> holger krekel wrote: > On Mon, Dec 21, 2009 at 10:11 +0100, Adam wrote: > > holger krekel wrote: > > > > > It makes py.test install as > > > > > > py.test # if python executable has basename 'python' > > > py.test3 # if python executable has version_info >= (3,0) > > > py.test2.x # if python executable has basename 'python2.x' (x in > > > '4567') py.test-jython # if we are running on jython2.5 > > > py.test-pypy # if we are running on pypy > > > > > > does this make sense to you, objections? > > > > I don't know how easy it will be to get this to work with > > debian's python-setup (or for any other distributor). > > good point. OTOH they anyway modify the setup.py Debian currently doesn't modify the setup.py. > so it's easy to implement their policy. It is not a policy matter. There might be a problem if the packager has different interpreters than the installer (package build vs. package install). I assume python-setup only uses python as interpreter so everything should be the same as now without the packager changing anything. > I believe python3 is currently the > standard so they probably should do 'py.test3' at least ... If you could offer a simple way to just create the py.testXX it should be possible to create them for every interpreter on the installed system (using the hook in python-setup). > (not sure who is doing py.test debian packaging currently, btw) Chris Lamb > That being said, i am considering to actually follow your suggestion > and implement the '-i' option. And also provide a py.test3 for python3. > > If you specify interpreters that don't exist what would you like py.test to > do? Bail out up-front or produce skips or ..? I don't have a strong opinion on this. I would favor skips or a warning. That would give an easy way to share which interpreters are supported without caring if they are installed on the specific developer machine. --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/20091221/ea4777c3/attachment-0001.pgp From dripton at ripton.net Mon Dec 21 19:38:53 2009 From: dripton at ripton.net (David Ripton) Date: Mon, 21 Dec 2009 10:38:53 -0800 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: <20091220214852.GB3516@trillke.net> References: <20091220214852.GB3516@trillke.net> Message-ID: <20091221183852.GA29551@vidar.dreamhost.com> On 2009.12.20 22:48:52 +0100, holger krekel wrote: > i just committed a change which i'd release together with a bunch > of other things as py-1.1.2. It makes py.test install as > > py.test # if python executable has basename 'python' > py.test3 # if python executable has version_info >= (3,0) > py.test2.x # if python executable has basename 'python2.x' (x in '4567') > py.test-jython # if we are running on jython2.5 > py.test-pypy # if we are running on pypy > > does this make sense to you, objections? It does for me because > i can more easily run tests with various interpreters. But > it means if you run "python2.4 setup.py install" you will not > get a 'py.test2.4' only, and no 'py.test' proper. I think it makes sense. I have a use case for your fix. Gentoo's py.test ebuild is currently not very useful if you have both Python 2 and Python 3 installed, because it makes /usr/bin/py.test point to Python 3 regardless of which version the user's has picked as the default Python using Gentoo's python-config. (IMO this is a bug, which I reported, but it was closed as wontfix.) I ended up having to keep Gentoo from installing Python 3 to keep them from breaking py.test. Your fix should make it easier for distros to let the scripts for multiple Python versions to coexist. -- David Ripton dripton at ripton.net From sridharr at activestate.com Tue Dec 22 06:09:31 2009 From: sridharr at activestate.com (Sridhar Ratnakumar) Date: Mon, 21 Dec 2009 21:09:31 -0800 Subject: [py-dev] py.test3, py.test-jython, py.test-pypy ... In-Reply-To: <20091220214852.GB3516@trillke.net> References: <20091220214852.GB3516@trillke.net> Message-ID: <4B30548B.6080706@activestate.com> On 12/20/2009 1:48 PM, holger krekel wrote: > Hi all, > > i just committed a change which i'd release together with a bunch > of other things as py-1.1.2. It makes py.test install as > > py.test # if python executable has basename 'python' > py.test3 # if python executable has version_info>= (3,0) > py.test2.x # if python executable has basename 'python2.x' (x in '4567') > py.test-jython # if we are running on jython2.5 > py.test-pypy # if we are running on pypy > > does this make sense to you, objections? It does for me because > i can more easily run tests with various interpreters. But > it means if you run "python2.4 setup.py install" you will no[w] > get a 'py.test2.4' only, and no 'py.test' proper. Hi Holger, I thought it is typical for packages to provide *both* the versions - i.e, foo.exe and foo-2.6.exe as demonstrated by, for instance, the easy_install script. Since third-party packagers such as Enstaller, PyPM[1] may use any interpreter binary ('python' or 'python2.6' - no guarantee) on their backend build machines, this change will always create a `py.test` script when 'python' is used to run setup.py. As a consequence, if the user installs pylib multiple times via different Python X.Y versions, there will be an overwrite of the main `py.test` script in the bin/ directory. This is not something that is generally desired (the user would rather want py.test-X.Y scripts[2]). If instead pylib installed both `py.test` and `py.test-X.Y` script regardless of the Python binary being used (as, I believe, currently done by the setuptools's entry points system), it would work around this limitation. Besides, I don't see any reason making it work otherwise (as originally proposed by holger). -srid *** [1] PyPM is the package manager from ActiveState; I am the developer of this project. [2] of relevance: http://jessenoller.com/2009/07/19/pep-370-per-user-site-packages-and-environment-stew/ From holger at merlinux.eu Tue Dec 22 19:46:42 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 22 Dec 2009 19:46:42 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <20091220214852.GB3516@trillke.net> References: <20091220214852.GB3516@trillke.net> Message-ID: <20091222184642.GW3516@trillke.net> Hi all, thanks for all your feedback! Here is a revised proposal: - for CPython interpreters: - always install py.test (so the last install wins) - additionally install py.test with a version suffix (sys.version_info[:2]) meaning: py.test2.4 py.test2.5 py.test3.1 etc. (if enough people prefer a dash before the version info, i'll do a dash :) - install the other little py.cleanup/py.lookup/py.svnwcrevert etc. development tools without version suffix - for PyPy and Jython: - install py.test-pypy, py.test-jython i.e.: no py.test proper and no version numbers (yet) - don't install the other development tools at all because it's unlikely users will want them to override the cpython mediated ones, particularly Jython which has a high startup overhead. Additionally i can imagine honoring an environment variable PYTEST_INHIBIT_VERSIONINSTALL=... which would inhibit the creation of py.test$SUFFIX binaries. This is useful for people working with virtual environments or PEP370 which already manages per-interpreter versions. Sounds fine? also on windows? cheers, holger From schmir at gmail.com Tue Dec 22 23:42:33 2009 From: schmir at gmail.com (schmir at gmail.com) Date: Tue, 22 Dec 2009 23:42:33 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <20091222184642.GW3516@trillke.net> (holger krekel's message of "Tue, 22 Dec 2009 19:46:42 +0100") References: <20091220214852.GB3516@trillke.net> <20091222184642.GW3516@trillke.net> Message-ID: <87ljguvdeu.fsf@brainbot.com> holger krekel writes: > Hi all, > > thanks for all your feedback! Here is a revised proposal: > > - for CPython interpreters: > - always install py.test (so the last install wins) > - additionally install py.test with a version suffix (sys.version_info[:2]) > meaning: py.test2.4 py.test2.5 py.test3.1 etc. > (if enough people prefer a dash before the version info, i'll do a dash :) > - install the other little py.cleanup/py.lookup/py.svnwcrevert etc. > development tools without version suffix > - for PyPy and Jython: > - install py.test-pypy, py.test-jython > i.e.: no py.test proper and no version numbers (yet) > - don't install the other development tools at all because it's unlikely > users will want them to override the cpython mediated ones, particularly > Jython which has a high startup overhead. > > Additionally i can imagine honoring an environment variable > > PYTEST_INHIBIT_VERSIONINSTALL=... > > which would inhibit the creation of py.test$SUFFIX binaries. > This is useful for people working with virtual environments > or PEP370 which already manages per-interpreter versions. > > Sounds fine? no. these things should really be handled by distribute (or setuptools/distutils). there is nothing special about the py.test script. just imagine a world where every python package X came with a custom X_INHIBIT_VERSIONINSTALL environment variable. If you really like it that way, try to persuade the distribute guys to implement that feature (probably with a switch in ~/.pydistutils.cfg) regards, - ralf From peloko45 at gmail.com Tue Dec 22 23:48:58 2009 From: peloko45 at gmail.com (Joan Miller) Date: Tue, 22 Dec 2009 22:48:58 +0000 Subject: [py-dev] Setup function at starting of all tests Message-ID: Hi everybody! How to run a setup function at all-tests level? I mean that it been run only at starting; and another one at the end --of all tests--. It's for setup and shutdown the logging. Thanks in advance! From holger at merlinux.eu Wed Dec 23 10:32:50 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 23 Dec 2009 10:32:50 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <87ljguvdeu.fsf@brainbot.com> References: <20091220214852.GB3516@trillke.net> <20091222184642.GW3516@trillke.net> <87ljguvdeu.fsf@brainbot.com> Message-ID: <20091223093250.GY3516@trillke.net> Hi Ralf, On Tue, Dec 22, 2009 at 23:42 +0100, schmir at gmail.com wrote: > holger krekel writes: > > > Hi all, > > > > thanks for all your feedback! Here is a revised proposal: > > > > - for CPython interpreters: > > - always install py.test (so the last install wins) > > - additionally install py.test with a version suffix (sys.version_info[:2]) > > meaning: py.test2.4 py.test2.5 py.test3.1 etc. > > (if enough people prefer a dash before the version info, i'll do a dash :) > > - install the other little py.cleanup/py.lookup/py.svnwcrevert etc. > > development tools without version suffix > > - for PyPy and Jython: > > - install py.test-pypy, py.test-jython > > i.e.: no py.test proper and no version numbers (yet) > > - don't install the other development tools at all because it's unlikely > > users will want them to override the cpython mediated ones, particularly > > Jython which has a high startup overhead. > > > > Additionally i can imagine honoring an environment variable > > > > PYTEST_INHIBIT_VERSIONINSTALL=... > > > > which would inhibit the creation of py.test$SUFFIX binaries. > > This is useful for people working with virtual environments > > or PEP370 which already manages per-interpreter versions. > > > > Sounds fine? > > no. these things should really be handled by distribute (or > setuptools/distutils). there is nothing special about the py.test > script. just imagine a world where every python package X came with a > custom X_INHIBIT_VERSIONINSTALL environment variable. which part do you disagree on? Everything? If so, I don't get it - does setuptools currently (pje and distribute variant) care for installing binaries with version-suffixes? Would it even generally make sense? Most scripts (see the the py.* helpers) probably don't need version suffixes. With py.test it's special because a user program runs in its very interpreter context (unless distributed testing is used) and testing against different interpreters is a common need. > If you really like it that way, try to persuade the distribute guys to > implement that feature (probably with a switch in ~/.pydistutils.cfg) Will see to talk to Tarek Ziade or other distutils people about this. Not sure i'd like to wait until that becomes mainstream and certainly don't want to try to convince PJE whose setuptools package is still in wide use. cheers, holger From schmir at gmail.com Wed Dec 23 11:41:56 2009 From: schmir at gmail.com (schmir at gmail.com) Date: Wed, 23 Dec 2009 11:41:56 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <20091223093250.GY3516@trillke.net> (holger krekel's message of "Wed, 23 Dec 2009 10:32:50 +0100") References: <20091220214852.GB3516@trillke.net> <20091222184642.GW3516@trillke.net> <87ljguvdeu.fsf@brainbot.com> <20091223093250.GY3516@trillke.net> Message-ID: <87oclq3rbf.fsf@muni.brainbot.com> holger krekel writes: > Hi Ralf, > >> > >> > Sounds fine? >> >> no. these things should really be handled by distribute (or >> setuptools/distutils). there is nothing special about the py.test >> script. just imagine a world where every python package X came with a >> custom X_INHIBIT_VERSIONINSTALL environment variable. > > which part do you disagree on? Everything? > > If so, I don't get it - does setuptools currently (pje and distribute variant) > care for installing binaries with version-suffixes? > afaik no > Would it even generally make sense? Most scripts (see the the py.* helpers) > probably don't need version suffixes. With py.test it's special because a user > program runs in its very interpreter context (unless distributed testing is > used) and testing against different interpreters is a common need. I disagree with this point. And even if I would agree, I still think that using the major and minor number as a suffix is insufficient for some people (think about the same interpreter version compiled for 32 or 64 bit architecture, or wide vs narrow unicode builds, or different compilers). > >> If you really like it that way, try to persuade the distribute guys to >> implement that feature (probably with a switch in ~/.pydistutils.cfg) > > Will see to talk to Tarek Ziade or other distutils people about this. makes sense. they are very responsive. I can see how this feature is useful to some people. > Not sure i'd like to wait until that becomes mainstream and certainly > don't want to try to convince PJE whose setuptools package is still > in wide use. that would probably take a long time... :) regards, - ralf From holger at merlinux.eu Wed Dec 23 12:10:16 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 23 Dec 2009 12:10:16 +0100 Subject: [py-dev] Setup function at starting of all tests In-Reply-To: References: Message-ID: <20091223111016.GZ3516@trillke.net> Hi Joan, On Tue, Dec 22, 2009 at 22:48 +0000, Joan Miller wrote: > Hi everybody! > > How to run a setup function at all-tests level? I mean that it been > run only at starting; and another one at the end --of all tests--. > > It's for setup and shutdown the logging. The current way to do pre/post-alltests setup is to have a conftest.py file at the root of your project containing the following hooks: # complete content of conftest.py def pytest_sessionstart(): # will be executed before tests are run def pytest_sessionfinish(): # will be executed after all tests have run The reason the conftest needs to be at the root level is for py.test to see it before tests are collected/run. Putting it into e.g. "testing/conftest.py" is fine as well if you run the tests with "py.test path/to/testing" usually. Here is some more info on hooks if you'd like to know more: http://codespeak.net/py/dist/test/customize.html HTH, holger From holger at merlinux.eu Wed Dec 23 12:17:20 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 23 Dec 2009 12:17:20 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <87oclq3rbf.fsf@muni.brainbot.com> References: <20091220214852.GB3516@trillke.net> <20091222184642.GW3516@trillke.net> <87ljguvdeu.fsf@brainbot.com> <20091223093250.GY3516@trillke.net> <87oclq3rbf.fsf@muni.brainbot.com> Message-ID: <20091223111719.GA3516@trillke.net> On Wed, Dec 23, 2009 at 11:41 +0100, schmir at gmail.com wrote: > holger krekel writes: > > Would it even generally make sense? Most scripts (see the the py.* helpers) > > probably don't need version suffixes. With py.test it's special because a user > > program runs in its very interpreter context (unless distributed testing is > > used) and testing against different interpreters is a common need. > > I disagree with this point. And even if I would agree, I still think > that using the major and minor number as a suffix is insufficient for > some people (think about the same interpreter version compiled for 32 or > 64 bit architecture, or wide vs narrow unicode builds, or different > compilers). Not sure how commonly people have this issue. It's common however in distros (see also mails from Adam, David and Sridhar) to have python$VER installs and it seems useful to have differentiated py.test for them. > >> If you really like it that way, try to persuade the distribute guys to > >> implement that feature (probably with a switch in ~/.pydistutils.cfg) > > > > Will see to talk to Tarek Ziade or other distutils people about this. > > makes sense. they are very responsive. I can see how this feature is > useful to some people. Just had a chat on #distutils with Tarek - we are not sure it's generally useful. After all, the general solution for the need for different interpreter contexts is to use virtualenv or PEP370 and most installed scripts have no need for the version-differentiations (easy_install/pip and py.test are exceptions because they want to run in whatever global or local context, that's part of their purpose). > > Not sure i'd like to wait until that becomes mainstream and certainly > > don't want to try to convince PJE whose setuptools package is still > > in wide use. > > that would probably take a long time... :) right, so if nobody else objects i am going to implement the suggested scheme :) I am open to generalize it and contribute to distribute later if there is a real need. cheers, holger From schmir at gmail.com Wed Dec 23 14:04:37 2009 From: schmir at gmail.com (schmir at gmail.com) Date: Wed, 23 Dec 2009 14:04:37 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <20091223111719.GA3516@trillke.net> (holger krekel's message of "Wed, 23 Dec 2009 12:17:20 +0100") References: <20091220214852.GB3516@trillke.net> <20091222184642.GW3516@trillke.net> <87ljguvdeu.fsf@brainbot.com> <20091223093250.GY3516@trillke.net> <87oclq3rbf.fsf@muni.brainbot.com> <20091223111719.GA3516@trillke.net> Message-ID: <87hbrh4za2.fsf@muni.brainbot.com> holger krekel writes: > > Just had a chat on #distutils with Tarek - we are not sure it's generally > useful. After all, the general solution for the need for different > interpreter contexts is to use virtualenv or PEP370 and most installed But your solution does not work for virtualenv (when using the same version of python). > scripts have no need for the version-differentiations (easy_install/pip > and py.test are exceptions because they want to run in whatever > global or local context, that's part of their purpose). > pip is no exception, just like easy_install and py.test are no exceptions. and just like py.which, which is no exception (hint: you'll probably also want to version that one) I use a pip script installed in ~/bin for different virtualenvs. there is no need to install the same pip version in different virtualenvs, nor is there a need to version the pip binary. This works for me cause it chooses the right python interpreter for me when I run it (i.e. I use "#! /usr/bin/env python" as a shebang). scons also uses an install scheme, where the scons script contains the above shebang and works with whatever python is first on PATH. btw. I've also ran py.test with the *wrong* python interpreter multiple times. versioning the py.test script would not have helped me a single time. spurred by this discussion I'm now creating a single file py.test script which includes the whole py library. This would allow people to drop that script in ~/bin/ and run it with any virtualenv they are using *without* installing the py lib first (well strictly speaking it is installed as a single file). What do you think about that? regards, - ralf From peloko45 at gmail.com Wed Dec 23 14:28:14 2009 From: peloko45 at gmail.com (Joan Miller) Date: Wed, 23 Dec 2009 13:28:14 +0000 Subject: [py-dev] Local import Message-ID: 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. ------------------------ 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)) ------------------------ From holger at merlinux.eu Wed Dec 23 15:13:00 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 23 Dec 2009 15:13:00 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <87hbrh4za2.fsf@muni.brainbot.com> References: <20091220214852.GB3516@trillke.net> <20091222184642.GW3516@trillke.net> <87ljguvdeu.fsf@brainbot.com> <20091223093250.GY3516@trillke.net> <87oclq3rbf.fsf@muni.brainbot.com> <20091223111719.GA3516@trillke.net> <87hbrh4za2.fsf@muni.brainbot.com> Message-ID: <20091223141259.GB3516@trillke.net> On Wed, Dec 23, 2009 at 14:04 +0100, schmir at gmail.com wrote: > holger krekel writes: > > > > > Just had a chat on #distutils with Tarek - we are not sure it's generally > > useful. After all, the general solution for the need for different > > interpreter contexts is to use virtualenv or PEP370 and most installed > > But your solution does not work for virtualenv (when using the same > version of python). why not? py.test$VER is installed additionally - what would break? (btw, i am looking around gentoo currently, seems they have something to do py.test-3.1, i.e. use a dash, and as easy_install is using a dash as well so i consider also going for that for uniformity). > > scripts have no need for the version-differentiations (easy_install/pip > > and py.test are exceptions because they want to run in whatever > > global or local context, that's part of their purpose). > > > > pip is no exception, just like easy_install and py.test are no > exceptions. and just like py.which, which is no exception (hint: you'll > probably also want to version that one) Hum, right. 'py.which' makes sense to be available per-interpreter as well. (For other's information: "py.which pkgname" tells where a package is imported from). > I use a pip script installed in ~/bin for different virtualenvs. there > is no need to install the same pip version in different virtualenvs, nor > is there a need to version the pip binary. This works for me cause it > chooses the right python interpreter for me when I run it (i.e. I use > "#! /usr/bin/env python" as a shebang). is there a windows equivalent for this? > scons also uses an install scheme, where the scons script contains the > above shebang and works with whatever python is first on PATH. is scons a single-file? Otherwise it needs to import its package and that must be installed for all such pythons or do you use PYTHONPATH for that? > btw. I've also ran py.test with the *wrong* python interpreter multiple > times. versioning the py.test script would not have helped me a single > time. ok. for me and judging from the feedback also for others it would help. > spurred by this discussion I'm now creating a single file py.test script > which includes the whole py library. This would allow people to drop > that script in ~/bin/ and run it with any virtualenv they are using > *without* installing the py lib first (well strictly speaking it is > installed as a single file). What do you think about that? Interesting. Curious how you approach this. Encoding a zip-file into the single-file? There is the matter of startup-time because there would be no sensible '.pyc' files. But OTOH distributing a single script is useful enough to make up for this penalty. If you try this and have issues feel free to drop by #pylib on freenode or mail here for help. Puh, it seems there are tons of different combinations of how python tools are packaged, distributed and used. Let me ask the other way around: would additional "py.test-$VER" targets present a problem for you? Eventually with i'd like to go for the "-i 2.4,2.5,2.6,jython,pypy-c" idea mentioned before. best, holger From holger at merlinux.eu Wed Dec 23 15:42:16 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 23 Dec 2009 15:42:16 +0100 Subject: [py-dev] Local import In-Reply-To: References: Message-ID: <20091223144216.GD3516@trillke.net> 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 peloko45 at gmail.com Wed Dec 23 16:00:56 2009 From: peloko45 at gmail.com (Joan Miller) Date: Wed, 23 Dec 2009 15:00:56 +0000 Subject: [py-dev] Local import In-Reply-To: <20091223144216.GD3516@trillke.net> References: <20091223144216.GD3516@trillke.net> Message-ID: That function would be used from each test file. So supposing that were added to i.e. py.path, then you have to add in each test file: import py py.path.import_local() And then you can access to you source files without installing them. Here is more clear about how is used: http://bitbucket.org/ares/scripy/src/f4dcdf53cba6/test/test_scripy/test_system.py It lets import the packages under 'lib': http://bitbucket.org/ares/scripy/src/f4dcdf53cba6/lib/ The great advantage is that you have not to run 'python setup.py develop' every time that you change your source files so it's very helpfull during development and testing. 2009/12/23 holger krekel : > 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 schmir at gmail.com Wed Dec 23 16:27:58 2009 From: schmir at gmail.com (schmir at gmail.com) Date: Wed, 23 Dec 2009 16:27:58 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <20091223141259.GB3516@trillke.net> (holger krekel's message of "Wed, 23 Dec 2009 15:13:00 +0100") References: <20091220214852.GB3516@trillke.net> <20091222184642.GW3516@trillke.net> <87ljguvdeu.fsf@brainbot.com> <20091223093250.GY3516@trillke.net> <87oclq3rbf.fsf@muni.brainbot.com> <20091223111719.GA3516@trillke.net> <87hbrh4za2.fsf@muni.brainbot.com> <20091223141259.GB3516@trillke.net> Message-ID: <87zl593e2p.fsf@muni.brainbot.com> holger krekel writes: > On Wed, Dec 23, 2009 at 14:04 +0100, schmir at gmail.com wrote: >> holger krekel writes: > > why not? py.test$VER is installed additionally - what would break? most probably nothing. but it would not help me either. > >> I use a pip script installed in ~/bin for different virtualenvs. there >> is no need to install the same pip version in different virtualenvs, nor >> is there a need to version the pip binary. This works for me cause it >> chooses the right python interpreter for me when I run it (i.e. I use >> "#! /usr/bin/env python" as a shebang). > > is there a windows equivalent for this? I use msys on windows and this also works. > > is scons a single-file? Otherwise it needs to import its package > and that must be installed for all such pythons or do you use > PYTHONPATH for that? no, it's not a single file. the scons script changes sys.path. the scons python package is installed in PREFIX/lib instead of PREFIX/lib/pyXY/site-packages. > >> btw. I've also ran py.test with the *wrong* python interpreter multiple >> times. versioning the py.test script would not have helped me a single >> time. > > ok. for me and judging from the feedback also for others it would help. > yes, you're probably right. But I still think this should be implemented in distutils. regards, - ralf From holger at merlinux.eu Wed Dec 23 16:35:50 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 23 Dec 2009 16:35:50 +0100 Subject: [py-dev] Local import In-Reply-To: References: <20091223144216.GD3516@trillke.net> Message-ID: <20091223153550.GE3516@trillke.net> On Wed, Dec 23, 2009 at 15:00 +0000, Joan Miller wrote: > That function would be used from each test file. So supposing that > were added to i.e. py.path, then you have to add in each test file: > > import py > py.path.import_local() > > And then you can access to you source files without installing them. > > Here is more clear about how is used: > http://bitbucket.org/ares/scripy/src/f4dcdf53cba6/test/test_scripy/test_system.py > > It lets import the packages under 'lib': > http://bitbucket.org/ares/scripy/src/f4dcdf53cba6/lib/ > > The great advantage is that you have not to run 'python setup.py > develop' every time that you change your source files so it's very > helpfull during development and testing. thanks, i see. I think you could as well just do it once in a conftest.py file and avoid the dynamic discovery. The Python import system caches imports so all subsequent modules importing "scripy" would pick up the previously imported one. Either way this makes it harder to run tests against the installed version of a package - which is nice to for checking if everything is correctly installed, i.e. no files, data etc. missing. Hum, we could think about adding a call to a new pytest_addsyspath() hook that could be put in a conftest.py file (and you could statically add ../lib to sys.path in your project) - and also introduce an option "--no-addsyspath" to prevent py.test from calling this hook. This should work and help projects to make things properly available during development but also run tests against an installed package. Makes sense to you? holger > > 2009/12/23 holger krekel : > > 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 > >> > > > > -- > > > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev -- From schmir at gmail.com Wed Dec 23 17:13:09 2009 From: schmir at gmail.com (schmir at gmail.com) Date: Wed, 23 Dec 2009 17:13:09 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <20091223141259.GB3516@trillke.net> (holger krekel's message of "Wed, 23 Dec 2009 15:13:00 +0100") References: <20091220214852.GB3516@trillke.net> <20091222184642.GW3516@trillke.net> <87ljguvdeu.fsf@brainbot.com> <20091223093250.GY3516@trillke.net> <87oclq3rbf.fsf@muni.brainbot.com> <20091223111719.GA3516@trillke.net> <87hbrh4za2.fsf@muni.brainbot.com> <20091223141259.GB3516@trillke.net> Message-ID: <87vdfx3bze.fsf@muni.brainbot.com> A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 3733 bytes Desc: not available Url : http://codespeak.net/pipermail/py-dev/attachments/20091223/5ee03e3b/attachment-0001.obj From peloko45 at gmail.com Wed Dec 23 18:09:21 2009 From: peloko45 at gmail.com (Joan Miller) Date: Wed, 23 Dec 2009 17:09:21 +0000 Subject: [py-dev] Local import In-Reply-To: <20091223153550.GE3516@trillke.net> References: <20091223144216.GD3516@trillke.net> <20091223153550.GE3516@trillke.net> Message-ID: 2009/12/23 holger krekel : > Hum, we could think about adding a call to a new pytest_addsyspath() hook > that could be put in a conftest.py file (and you could statically add ../lib > to sys.path in your project) - and also introduce an option "--no-addsyspath" to > prevent py.test from calling this hook. ?This should work and help > projects to make things properly available during development but also > run tests against an installed package. > > Makes sense to you? Yes, of course :) From peloko45 at gmail.com Wed Dec 23 18:49:04 2009 From: peloko45 at gmail.com (Joan Miller) Date: Wed, 23 Dec 2009 17:49:04 +0000 Subject: [py-dev] Local import In-Reply-To: <20091223153550.GE3516@trillke.net> References: <20091223144216.GD3516@trillke.net> <20091223153550.GE3516@trillke.net> Message-ID: 2009/12/23 holger krekel : > thanks, i see. I think you could as well just do it once in a conftest.py file > and avoid the dynamic discovery. The Python import system caches imports so all > subsequent modules importing "scripy" would pick up the previously imported one. You've reason; it works well from conftest.py file. Now I changed it to avoid the discovery: ------------------ def import_local(source='lib'): """Inserts local library on 'sys.path'.""" current_dir = os.path.abspath(os.path.dirname(__file__)) sys.path.insert(0, os.path.join(os.path.dirname(current_dir), source)) ------------------ From holger at merlinux.eu Wed Dec 23 19:22:54 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 23 Dec 2009 19:22:54 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <87vdfx3bze.fsf@muni.brainbot.com> References: <20091220214852.GB3516@trillke.net> <20091222184642.GW3516@trillke.net> <87ljguvdeu.fsf@brainbot.com> <20091223093250.GY3516@trillke.net> <87oclq3rbf.fsf@muni.brainbot.com> <20091223111719.GA3516@trillke.net> <87hbrh4za2.fsf@muni.brainbot.com> <20091223141259.GB3516@trillke.net> <87vdfx3bze.fsf@muni.brainbot.com> Message-ID: <20091223182254.GF3516@trillke.net> Hi Ralf, very cool! Just needs some fixing for Python3. I just gave your write access on bitbucket py-trunk - would you care to add bin-for-dist/generate_standalone_pytest.py? (if in doubt i can do the python3 fixing) And do you think it makes sense to honour "py.XYZ" symlinks pointing to 'py.test' which would make the other tools available without duplication? cheers, holger On Wed, Dec 23, 2009 at 17:13 +0100, schmir at gmail.com wrote: > holger krekel writes: > > > > >> spurred by this discussion I'm now creating a single file py.test script > >> which includes the whole py library. This would allow people to drop > >> that script in ~/bin/ and run it with any virtualenv they are using > >> *without* installing the py lib first (well strictly speaking it is > >> installed as a single file). What do you think about that? > > > > Interesting. Curious how you approach this. Encoding a zip-file into > > the single-file? There is the matter of startup-time because > > there would be no sensible '.pyc' files. But OTOH distributing a > > single script is useful enough to make up for this penalty. > > If you try this and have issues feel free to drop by #pylib on freenode > > or mail here for help. > > it uses base64-encoded zlib-compressed pickled source code and a custom > importer object. > > I've created a git repo on github: > http://github.com/schmir/standalone-py.test > > You'll have to run the following commands in order to checkout and > create a single file: > > ,---- > | git clone git://github.com/schmir/standalone-py.test.git > | python standalone-py.test/generate-single-file.py > | cp standalone-py.test/py.test ~/bin/ > `---- > > or you could download the script from: > > http://schmir.github.com/standalone-py.test/py.test > > I'm also attaching a patch against py-1.1.1. > > Regards, > - Ralf > -- From holger at merlinux.eu Wed Dec 23 21:40:51 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 23 Dec 2009 21:40:51 +0100 Subject: [py-dev] execnet-1.0.2: channel-over-channels / bug fixes Message-ID: <20091223204051.GG3516@trillke.net> execnet is a small stable pure-python library for working with local or remote clusters of Python interpreters, with ease. The 1.0.2 release is fully backward compatible and: - introduces a generalized way to send channels over channels - makes gateways more resilient against callback failures - speeds up local gateway creation, now at <50ms on an old 1.5GHZ machine - fixes a bug in channel.receive() which could wrongly timeout More info, new tested examples and links to blog entries here: http://codespeak.net/execnet cheers and i wish you all relaxed days of this decade, holger changes in 1.0.2 -------------------------------- - generalize channel-over-channel sending: you can now have channels anywhere in a data structure (i.e. as an item of a container type). Add according examples. - automatically close a channel when a remote callback raises an exception, makes communication more robust because until now failing callbacks rendered the receiverthread unuseable leaving the remote side in-accessible. - internally split socket gateways, speeds up popen-gateways by 10% (now at <50 milliseconds per-gateway on a 1.5 GHZ machine) - fix bug in channel.receive() that would wrongly raise a TimeoutError after 1000 seconds (thanks Ronny Pfannschmidt) From schmir at gmail.com Sun Dec 27 23:41:50 2009 From: schmir at gmail.com (schmir at gmail.com) Date: Sun, 27 Dec 2009 23:41:50 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <20091223182254.GF3516@trillke.net> (holger krekel's message of "Wed, 23 Dec 2009 19:22:54 +0100") References: <20091220214852.GB3516@trillke.net> <20091222184642.GW3516@trillke.net> <87ljguvdeu.fsf@brainbot.com> <20091223093250.GY3516@trillke.net> <87oclq3rbf.fsf@muni.brainbot.com> <20091223111719.GA3516@trillke.net> <87hbrh4za2.fsf@muni.brainbot.com> <20091223141259.GB3516@trillke.net> <87vdfx3bze.fsf@muni.brainbot.com> <20091223182254.GF3516@trillke.net> Message-ID: <874onc59ap.fsf@brainbot.com> holger krekel writes: > Hi Ralf, > > very cool! Just needs some fixing for Python3. > I just gave your write access on bitbucket py-trunk - would you care > to add bin-for-dist/generate_standalone_pytest.py? just added it. > (if in doubt i can do the python3 fixing) please do so. I can certainly get it working with python 3, but I'm not quite sure what's best practice. One thing that needs to be fixed is the relative "import defaultconftest" that I introduced. I just do not know how to workaround the py.apipkg magic. > > And do you think it makes sense to honour "py.XYZ" symlinks pointing > to 'py.test' which would make the other tools available without duplication? in case anyone uses those (or even the standalone py.test): yes. - ralf From holger at merlinux.eu Mon Dec 28 09:53:11 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 28 Dec 2009 09:53:11 +0100 Subject: [py-dev] revised proposal for py.test/tool install In-Reply-To: <874onc59ap.fsf@brainbot.com> References: <20091222184642.GW3516@trillke.net> <87ljguvdeu.fsf@brainbot.com> <20091223093250.GY3516@trillke.net> <87oclq3rbf.fsf@muni.brainbot.com> <20091223111719.GA3516@trillke.net> <87hbrh4za2.fsf@muni.brainbot.com> <20091223141259.GB3516@trillke.net> <87vdfx3bze.fsf@muni.brainbot.com> <20091223182254.GF3516@trillke.net> <874onc59ap.fsf@brainbot.com> Message-ID: <20091228085311.GI3516@trillke.net> Hi Ralf, On Sun, Dec 27, 2009 at 23:41 +0100, schmir at gmail.com wrote: > holger krekel writes: > > > Hi Ralf, > > > > very cool! Just needs some fixing for Python3. > > I just gave your write access on bitbucket py-trunk - would you care > > to add bin-for-dist/generate_standalone_pytest.py? > > just added it. great, thanks. MIT-licensing is fine for you, btw? > > (if in doubt i can do the python3 fixing) > > please do so. I can certainly get it working with python 3, but I'm not > quite sure what's best practice. One thing that needs to be fixed is the > relative "import defaultconftest" that I introduced. I just do not know > how to workaround the py.apipkg magic. It's not about apipkg, it's about importing the defaultconftest.py starting from its file location which, it being part of a zip-file, does not work. This loading-by-filename is done for uniformity with loading other conftest.py files. However, i guess here we can instead just always import py.impl.test.defaultconftest by python import path. > > And do you think it makes sense to honour "py.XYZ" symlinks pointing > > to 'py.test' which would make the other tools available without duplication? > > in case anyone uses those (or even the standalone py.test): yes. not sure either how many people use py.cleanup/py.lookup etc. I am sure, though, that people are interested in the standalone py.test version, i have been asked for it a number of times. Actually I guess some maintainers would appreciate a py.test --genscript=mytest [options] [paths] which generate a custom "mytest" standalone script to be shipped with a package or offered for download for users to run tests in their environment. cheers, holger From peloko45 at gmail.com Thu Dec 31 12:58:07 2009 From: peloko45 at gmail.com (Joan Miller) Date: Thu, 31 Dec 2009 11:58:07 +0000 Subject: [py-dev] Class instance at module level Message-ID: Is pssible to instance a class at module level (setup_module) and that it can be used from a test class? From holger at merlinux.eu Thu Dec 31 13:05:22 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 31 Dec 2009 13:05:22 +0100 Subject: [py-dev] Class instance at module level In-Reply-To: References: Message-ID: <20091231120522.GT3516@trillke.net> On Thu, Dec 31, 2009 at 11:58 +0000, Joan Miller wrote: > Is pssible to instance a class at module level (setup_module) and that > it can be used from a test class? Do you mean like this: class MyClass: pass def setup_module(mod): mod.myclass = MyClass() # put instance to module globals class TestHello: def test_world(self): x = myclass # use module-global myclass instance ... ? If not, can you provide an example? cheers, holger From peloko45 at gmail.com Thu Dec 31 13:25:07 2009 From: peloko45 at gmail.com (Joan Miller) Date: Thu, 31 Dec 2009 12:25:07 +0000 Subject: [py-dev] Class instance at module level In-Reply-To: <20091231120522.GT3516@trillke.net> References: <20091231120522.GT3516@trillke.net> Message-ID: Yes, it was that. Thanks for the fast answer 2009/12/31 holger krekel : > On Thu, Dec 31, 2009 at 11:58 +0000, Joan Miller wrote: >> Is pssible to instance a class at module level (setup_module) and that >> it can be used from a test class? > > Do you mean like this: > > ? ?class MyClass: > ? ? ? ?pass > > ? ?def setup_module(mod): > ? ? ? ?mod.myclass = MyClass() # put instance to module globals > > ? ?class TestHello: > ? ? ? ?def test_world(self): > ? ? ? ? ? ?x = myclass # use module-global myclass instance > ? ? ? ? ? ?... > > ? > > If not, can you provide an example? > > cheers, > holger > From peloko45 at gmail.com Thu Dec 31 18:25:52 2009 From: peloko45 at gmail.com (Joan Miller) Date: Thu, 31 Dec 2009 17:25:52 +0000 Subject: [py-dev] funcarg in a class Message-ID: 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 -------------------------- http://codespeak.net/py/dist/test/funcargs.html From pedronis at openend.se Thu Dec 31 22:35:34 2009 From: pedronis at openend.se (Samuele Pedroni) Date: Thu, 31 Dec 2009 22:35:34 +0100 Subject: [py-dev] [py-svn] py-trunk commit 3b9141d6bd7d: internal: always use scripts found in the environment In-Reply-To: <20091231151533.A235A7EEDE@bitbucket.org> References: <20091231151533.A235A7EEDE@bitbucket.org> Message-ID: <4B3D1926.2060206@openend.se> this broke the way I tend to run the oejskit tests which use testdir.runpytest for some functional tests, I tend to setup a virtualenv in which the current py.test trunk is installed via setup.py develop, path-to-virtualenv/bin/py.test then is how I invoke py.test and it that case there is no py.test at all findable through the environment. commits-noreply at bitbucket.org wrote: > # HG changeset patch -- Bitbucket.org > # Project py-trunk > # URL http://bitbucket.org/hpk42/py-trunk/overview/ > # User holger krekel > # Date 1262272511 -3600 > # Node ID 3b9141d6bd7df061b8f4bace364d1ea66fb0fe16 > # Parent 2f97b1b6a2cc27197238679b991a8e6a289f65b1 > internal: always use scripts found in the environment > > --- a/py/plugin/pytest_pytester.py > +++ b/py/plugin/pytest_pytester.py > @@ -307,13 +307,8 @@ class TmpTestdir: > return self.run(*fullargs) > > def _getpybinargs(self, scriptname): > - bindir = py._dir.dirpath('bin') > - if not bindir.check(): > - script = py.path.local.sysfind(scriptname) > - else: > - script = bindir.join(scriptname) > - assert script.check() > - return py.std.sys.executable, script > + script = py.path.local.sysfind(scriptname) > + return script, > > def runpython(self, script): > return self.run(py.std.sys.executable, script) > _______________________________________________ > py-svn mailing list > py-svn at codespeak.net > http://codespeak.net/mailman/listinfo/py-svn >