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: 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: 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> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 3733 bytes Desc: not available URL: 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 >