Mailman 3 April 2005 - pytest-dev

[py-dev] execnet hangs
by Armin Rigo April 8, 2005

April 8, 2005

Hi, I'm having a hard time debugging the following example, which just hangs on the very last receive(). On the remote site, the CHANNEL_DATA message from the last send() shows up in the debug log, but it doesn't get passed to my 'for' loop... Armin -+- import py code = py.code.Source( """ for name, args in channel: channel.send(1) """) gw = py.execnet.SshGateway('codespeak.net') def do(c, name, *args): c.send((name, args)) obj = c.receive() print obj return obj c1 = gw.remote_exec(code) do(c1, 'stat', '/.') c2 = gw.remote_exec(code) do(c2, 'readdir', '/') c3 = gw.remote_exec(code) do(c3, 'readdir', '/home')

3 8

[py-dev] Re: cmdline options / rev 10344
by holger krekel April 8, 2005

April 8, 2005

Hi Armin, i CCed to py-dev in case others are interested (beware everyone, we are touching some deeper implementation issues here). The following discussion starts off at the py-collect refactoring of cmdline option handling with respect to projects having custom command line options for py.test. On Fri, Apr 08, 2005 at 09:25 +0100, Armin Rigo wrote: > On Tue, Apr 05, 2005 at 07:38:28PM +0200, holger krekel wrote: > > if you feel like it it would be great if you would > > comment on rev 10344 on the py.test branch (i took > > care to write a hopefully understandable log message). > > Well, this problem is messy (did we mention that already?) and I think you > have found a quite reasonable solution. The "no-API" paradigm doesn't really > apply around conftest files anyway: if I look at PyPy's, they depend on quite > a lot of internal py.test stuff. Having to actually call back a py.test.xyz() > function doesn't change much. Except that it is more obvious how you can get at the resulting values of custom Option definitions. The idea is to try to reduce the globalness of the py.test API (and py.test.option.SOMETHING is pretty global ...). > Maybe conftest doesn't have to know about the Option class? I mean, instead > of py.test.addoptions('group', Option(...), Option(...)) we could have > something like multiple calls to py.test.addoption('group', ...). Yes, well, i agree to the intention but they are practical problems. Single calls would make it non-obvious how to get to the "option" value container from the conftest.py side. And passing a list of tuples or something would deride the use of named arguments (which is the only way to somehow maintain readable code). Unfortuantely, I didn't find out a way out of this mind-looping considerations so far. > I guess I'll review the rest of the py-collect branch sometime soon... Here are a few particularly interesting areas: - there is a file called "py/documentation/releasescheme.txt" which describes the planned approach towards releasing the py lib. I'd like PyPy to follow the same conventions so it makes double sense if you take a critical look. - regarding reducing import mess: py.test now uses py.path.local().pyimport() with a previously discussed algorithm of constructing a package name and consulting the root package's __package__.importfrompath() to get to a canonical module import. I am thinking of somehow keeping getpymodule()'s functionality of loading c-modules on the fly but otherwise completly deleting all stuff related to custom import hooks. This derides us of having "direct remote imports" but i think that's kind of a hopeless mess and somewhat unreal anyway (we can move the custom import hook hacks to some private directory to be able to reinstate it more easily if need be). In effect, for execnet we probably want to settle on an (efficient) filetransfer protocol but otherwise just do local imports. Are we going to cry tears not having our own custom import hook anymore? I don't think so. - Collectors are Items are Collectors: they merged quite a bit and have uniform signatures as seen from the (previously named 'Driver') Session. The following properties are true for any collector or item (usually named 'colitem' in the code): assert hasattr(colitem, 'name') assert colitem.parent is None or isinstance(colitem.parent, Collector) res = colitem.run() assert isiterable(res) or res is None # if res is iterable the session recurses into it if isiterable(res): for x in res: assert isinstance(x, CollectorOrItem) # a colitem can be reconstructed from a root collector and a # list of names colitems = colitem.listchain() current = colitems.pop(0) while colitems: current = current.join(colitems.pop(0).name) assert current == colitem To see a concrete tree of collectors/items, you can issue:: py.test --collectonly which shows more output than on the current trunk. ok, that should be enough for starters :-) The idea is that after the merge of the branch i soon want to cut a py-0.8.0 release and beta-test the release process. Guaruantees regarding APIs will only become effective after a py-1.0.0 which i want to have before EuroPython. cheers, holger

1 0

[py-dev] Error with py.test and scipy ...
by Pierre Barbier de Reuille April 7, 2005

April 7, 2005

Hello, I just tried to use py.test. However, I experience segmentation fault when importing scipy module. Did anyone have the same problem before ? Is there a way to avoid it ? Thanks, Pierre -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68

1 2

[py-dev] Minor doc problem with py.test
by Roy Smith April 5, 2005

April 5, 2005

I'm new to the list, so I'm not sure what the right procedure is for reporting these things. I assume somebody will set me straight if this list isn't it :-) In http://codespeak.net/py/current/doc/test.html#automatic-collection-of- tests-on-all-levels, it says, "The automated test collection process collects files from all subdirectories with a leading test_ in their filename". I had to read it a few times to understand that "with a leading test_" applied to the individual filenames, not the directory names. It might be clearer to say something like: "The automated test collection process walks the current directory and all subdirectories (except those starting with a ".") and collects files with a leading test_ in their filename"

2 1

[py-dev] Re: [py-svn] r10293 - in py/branch/py-collect: bin test/tkinter test/tkinter/icons
by holger krekel April 4, 2005

April 4, 2005

Hi Jan, On Mon, Apr 04, 2005 at 17:32 +0200, jan(a)codespeak.net wrote: > Author: jan > Date: Mon Apr 4 17:32:41 2005 > New Revision: 10293 > > Added: > py/branch/py-collect/bin/py.test.tkinter (contents, props changed) > py/branch/py-collect/test/tkinter/ > ... thanks for committing, i have a few preliminary comments ... - would you mind respecting http://codespeak.net/py/current/doc/coding-style.html and in particular "no plural names in directory and file names"? - would it be hard to get your code 2.2 (at least 2.3) compatible? the py lib and py.test aim to run on python2.2 and upwards ... cheers, holger

1 0

[py-dev] py.test tkinter frontend
by Jan Balster April 3, 2005

April 3, 2005

Hello, i finished my rewrite of a tkinter-frontend for py.test. what's the best way to share it? i can post a screenshot and a tar.gz file (35kb). some informations about the package: it lives under py/test/gui and works only in the py-collect branch. it provides a tree view for all tests. every test can be executed just by double clicking it. the frontend watches all files and directories specified at the command line. if a test fails, a text widget shows a report similar to the current report by py.test (it uses TerminalDriver). all filenames in a report are links and open a text editor (see tkgui.py/TkMain.launch_editor) to show the point of failure. if a test fails the frontend calls tkinter.bell(), so you can hear if your changes break some code (should be an option). --collectonly, --nocapture, --showlocals , --fulltrace, --nomagic, should work as expected. todo: * documentation, documentation * more tests ;-) * replace hack for config.py and conftest.py !! * patch drive.py/Driver.runone -> call finish after the captured output is set (see py.test.gui.guidriver.py/GuiDriver.runone) * improve performance of tree widget when updating test results!! i would appreciate your feedback and comments! thank you! jan

2 1

[py-dev] anybody using conftest.py?
by hpk＠trillke.net April 2, 2005

April 2, 2005

hi especially py.test users, i am wondering if any of you are using (the undocumented) "conftest.py" files within your projects where you use py.test. If so, please describe briefly what you are doing with it. I want to merge the collect-branch real soon now and this will involve changes to customizations people might have been doing via conftest.py files. If you don't know what i am talking about, fine: forget it :-) One case where i will need to care is PyPy which already uses test-customization heavily. cheers, holger

1 0

[py-dev] py.test and --session, re-run failures only
by Martin Blais April 2, 2005

April 2, 2005

hi guys my first post on this list. thanks for py.test, it's very nice, i'm in the process of converting my cr*ppy unittest hacks into something a little cleaner by using py.test. in the past, i wrote some testing infrastructure for a large C++ project in the past, i hope i can contribute something to this project in the future. 1. so i'm checking out py.test and i run across this: --session run a test session/rerun only failing tests. "rerun only failing tests" lets me think that somehow the session is recording somewhere (e.g. in a file) which tests have failed and only reruns those tests. in fact, fiddling in the code and running it, i realized that it just runs a subprocess and monitors file changes (by polling), and then automatically reruns the tests. perhaps the help string should be clarified. in any case, it would be a cool feature to be able to record which tests fail and then to be able to rerun just the ones which failed in the past. we used to have that in my previous job, and it was very useful, we had LOTS of tests, and running them was very slow, so just rerunniing the failures was a great timesaver. 2. i would like to be able to say "run just this one test", by specifying the method, e.g. test_search.py:TestSearch.test_simple, or perhaps some kind simpler pattern matching. this is why i started fiddling in the code. i would probably modify the driver to filter down the wanted methods once the collector has passed. any comments on how to go about this welcome. thanks, cheers,

3 4