From issues-noreply at bitbucket.org Wed Jun 9 03:55:24 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Wed, 09 Jun 2010 01:55:24 -0000 Subject: [py-dev] New issue 104 in py-trunk: xml output does not escape "<" ? Message-ID: <635183120d30af5c76c6e37d7fe0aa63@bitbucket.org> --- you can reply above this line --- New issue 104: xml output does not escape "<" ? http://bitbucket.org/hpk42/py-trunk/issue/104/xml-output-does-not-escape Anonymous on Wed, 9 Jun 2010 03:55:24 +0200: Description: Hello, The xml plugin doesn't escape "<" chars in the name attrib so hudson fails to parse the file. I renamed the generated test as a workaround. The plugin should be escaping since it's xml should it not? -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From memedough at gmail.com Wed Jun 9 12:13:09 2010 From: memedough at gmail.com (meme dough) Date: Wed, 9 Jun 2010 20:13:09 +1000 Subject: [py-dev] pytest-cov options Message-ID: Hi, The next version of coverage will be 3.4 and looks like it will contain a (nice) backward incompatible change. It has include and omit which are fnmatch patterns. Ned also mentioned that in addition there may be able to specify the roots of source code (but I haven't seen any code for this one yet). For pytest-cov I am considering refining to the options below. coverage reporting with distributed testing support: --cov=pat include coverage for filename pattern (multi-allowed) --cov-omit=pat exclude coverage for filename pattern (multi-allowed) --cov-report=type type of report to generate: term, term-missing, annotate, html, xml (multi-allowed) --cov-combine-each for dist=each mode produce a single combined report --cov-config-file=path config file for coverage, default: .coveragerc This seems to work nicely, though it means you always have to specify like "my/source/root/*" for both --cov and --cov-omit. If the other option added then I will probably add one more so that it is in line with coverage. I haven't committed yet and still playing but wanted to see if anyone had any suggestions. :) From holger at merlinux.eu Wed Jun 9 14:55:23 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 9 Jun 2010 14:55:23 +0200 Subject: [py-dev] pytest-cov options In-Reply-To: References: Message-ID: <20100609125522.GC17693@trillke.net> Hi Meme, On Wed, Jun 09, 2010 at 20:13 +1000, meme dough wrote: > The next version of coverage will be 3.4 and looks like it will > contain a (nice) backward incompatible change. It has include and > omit which are fnmatch patterns. Ned also mentioned that in addition > there may be able to specify the roots of source code (but I haven't > seen any code for this one yet). do you know, is there going to be pytest-coverage plugin included by default? > For pytest-cov I am considering refining to the options below. > > coverage reporting with distributed testing support: > --cov=pat include coverage for filename pattern (multi-allowed) > --cov-omit=pat exclude coverage for filename pattern (multi-allowed) > ... > This seems to work nicely, though it means you always have to specify > like "my/source/root/*" for both --cov and --cov-omit. If the other > option added then I will probably add one more so that it is in line > with coverage. my comments: a) I guess you could also specify path relative to the CWD and they could be expanded before passing it on. Makes them shorter. b) is the "exclude" pattern applied after the include-pattern? c) is it possible to specify python module/package names? d) can the patterns above not be specified in the coverage rc file? > --cov-report=type type of report to generate: term, term-missing, > annotate, html, xml (multi-allowed) > --cov-combine-each for dist=each mode produce a single combined report why not make this the default if --dist=each is specified? I don't imagine i'd be interested in separate reports if running --dist-each. And if so, i can still run with just one target. > --cov-config-file=path > config file for coverage, default: .coveragerc --cov-config=path is enough i think. > I haven't committed yet and still playing but wanted to see if anyone > had any suggestions. let me/py-dev when you do so i can play around with it a bit after which i can hopefully make more substantiated comments :) holger From issues-noreply at bitbucket.org Wed Jun 9 15:19:05 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Wed, 09 Jun 2010 13:19:05 -0000 Subject: [py-dev] New issue 105 in py-trunk: Internal TypeError when assert is on a line with multiple commands and the assertion fails Message-ID: <0f0041650667ca85c0518344f7e4e3e7@bitbucket.org> --- you can reply above this line --- New issue 105: Internal TypeError when assert is on a line with multiple commands and the assertion fails http://bitbucket.org/hpk42/py-trunk/issue/105/internal-typeerror-when-assert-is-on-a-line-with-multiple-commands-and-the-assertion David Horat / davidhorat on Wed, 9 Jun 2010 15:19:05 +0200: Description: When I run py.test over the attached file test_py_error.py I got an Exception TypeError from py code. This seems to be with some parsing problem because it only appears when we have an assert on the a line with multiple commands and the assertion fails. The code and output files attached are self explanatory. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From issues-noreply at bitbucket.org Sat Jun 12 19:35:46 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sat, 12 Jun 2010 17:35:46 -0000 Subject: [py-dev] New issue 106 in py-trunk: multiline statement in import error looks bogus Message-ID: --- you can reply above this line --- New issue 106: multiline statement in import error looks bogus http://bitbucket.org/hpk42/py-trunk/issue/106/multiline-statement-in-import-error-looks fijal on Sat, 12 Jun 2010 19:35:46 +0200: Description: Attached simple example. Basically I think it's important to have the whole statement presented in case it's a multiline statement. This applies only when there is an error during import Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From issues-noreply at bitbucket.org Sat Jun 12 19:39:51 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sat, 12 Jun 2010 17:39:51 -0000 Subject: [py-dev] New issue 107 in py-trunk: --pdb does not work with import error Message-ID: --- you can reply above this line --- New issue 107: --pdb does not work with import error http://bitbucket.org/hpk42/py-trunk/issue/107/pdb-does-not-work-with-import-error fijal on Sat, 12 Jun 2010 19:39:51 +0200: Description: When import fails, --pdb does not enter pdb (and instead exits py.test) Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From holger at merlinux.eu Mon Jun 14 15:18:40 2010 From: holger at merlinux.eu (holger krekel) Date: Mon, 14 Jun 2010 15:18:40 +0200 Subject: [py-dev] quick poll: collection errors and --pdb In-Reply-To: References: Message-ID: <20100614131840.GJ17693@trillke.net> Hi all, quick polling ... related to the below issue: did you miss being able to say "--pdb" on collection errors (import errors, syntax errors, errors during code-execution-at-import time)? Or the other way round: would you mind if it did also enter the PDB prompt in that case? best, holger On Sat, Jun 12, 2010 at 17:39 -0000, issues-noreply at bitbucket.org wrote: > --- you can reply above this line --- > > New issue 107: --pdb does not work with import error > http://bitbucket.org/hpk42/py-trunk/issue/107/pdb-does-not-work-with-import-error > > fijal on Sat, 12 Jun 2010 19:39:51 +0200: > > Description: > When import fails, --pdb does not enter pdb (and instead exits py.test) > > Responsible: > hpk42 > -- > This is an issue notification from bitbucket.org. > You are receiving this either because you are the > owner of the issue, or you are following the issue. > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From cfbolz at gmx.de Mon Jun 14 15:21:39 2010 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 14 Jun 2010 15:21:39 +0200 Subject: [py-dev] quick poll: collection errors and --pdb In-Reply-To: <20100614131840.GJ17693@trillke.net> References: <20100614131840.GJ17693@trillke.net> Message-ID: <4C162CE3.201@gmx.de> Hi Holger, On 06/14/2010 03:18 PM, holger krekel wrote: > related to the below issue: did you miss being able to say "--pdb" > on collection errors (import errors, syntax errors, errors during > code-execution-at-import time)? Or the other way round: would you > mind if it did also enter the PDB prompt in that case? I probably wouldn't mind, but I don't remember ever needing this. While we are talking about --pdb: what kind of bugs me is that xfailing tests drop into a debugger when they fail. I already *know* about this failure, so usually I don't want that. Cheers, Carl Friedrich From holger at merlinux.eu Tue Jun 15 12:20:34 2010 From: holger at merlinux.eu (holger krekel) Date: Tue, 15 Jun 2010 12:20:34 +0200 Subject: [py-dev] py.test talk at DZUG/Dresden? Message-ID: <20100615102034.GN17693@trillke.net> Hi all, i have been asked to talk at http://new.zope.de/tagung/Dresden_2010 about py.test. But i can't make it there for personal reasons. Anybody interested in giving a talk about py.test status? If so, drop me a note - i am happy to help prepare. best, holger -- From holger at merlinux.eu Wed Jun 16 13:20:49 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 16 Jun 2010 13:20:49 +0200 Subject: [py-dev] quick poll: collection errors and --pdb In-Reply-To: <4C162CE3.201@gmx.de> References: <20100614131840.GJ17693@trillke.net> <4C162CE3.201@gmx.de> Message-ID: <20100616112049.GR17693@trillke.net> Hi Carl Friedrich, On Mon, Jun 14, 2010 at 15:21 +0200, Carl Friedrich Bolz wrote: > Hi Holger, > > On 06/14/2010 03:18 PM, holger krekel wrote: > > related to the below issue: did you miss being able to say "--pdb" > > on collection errors (import errors, syntax errors, errors during > > code-execution-at-import time)? Or the other way round: would you > > mind if it did also enter the PDB prompt in that case? > > I probably wouldn't mind, but I don't remember ever needing this. Actually i just tried entering PDB on an import error and it seems that locals/globals don't have meaningful values if the import fails. So --pdb would not be of much use anyway. > While we are talking about --pdb: what kind of bugs me is that xfailing > tests drop into a debugger when they fail. I already *know* about this > failure, so usually I don't want that. sure, thanks for reporting. i just fixed this in py-trunk, also unified traceback reporting between --pdb and non-pdb mode. best, holger From red_socks at gmx.de Thu Jun 24 16:35:59 2010 From: red_socks at gmx.de (Frank Hempel) Date: Thu, 24 Jun 2010 16:35:59 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour Message-ID: <20100624143559.234190@gmx.net> Hello, I experienced the possibility of funcarg name clashes when defining the funcarg factories in conftest.py. Lets say there are two project directories side by side and each has it "own" conftest.py. If both conftest.py's define a funcarg factory for the the same funcarg-name only the factory of the last loaded conftest.py is the one used for both directories. And this holds also when I start the py.test-command from within a project directory. If i'm in bad luck I get the funcargs from the project' conftest.py sitting next to me (and there is actually the chance of other side-effects from the configure/unconfigure methods of the others project conftest.py). I encountered this problem when i integrated third party projects into mine via svn:externals. Maybe i overlooked it, is there the possibility to change the behaviour of loading the conftest.py's? Thanks you, best regards, Frank -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl From holger at merlinux.eu Thu Jun 24 16:40:58 2010 From: holger at merlinux.eu (holger krekel) Date: Thu, 24 Jun 2010 16:40:58 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <20100624143559.234190@gmx.net> References: <20100624143559.234190@gmx.net> Message-ID: <20100624144057.GD14601@trillke.net> Hello Frank, On Thu, Jun 24, 2010 at 16:35 +0200, Frank Hempel wrote: > Hello, > > I experienced the possibility of funcarg name clashes when defining the funcarg factories in conftest.py. Lets say there are two project directories side by side and each has it "own" conftest.py. If both conftest.py's define a funcarg factory for the the same funcarg-name only the factory of the last loaded conftest.py is the one used for both directories. > And this holds also when I start the py.test-command from within a project directory. If i'm in bad luck I get the funcargs from the project' conftest.py sitting next to me (and there is actually the chance of other side-effects from the configure/unconfigure methods of the others project conftest.py). > > I encountered this problem when i integrated third party projects into mine via svn:externals. > > Maybe i overlooked it, is there the possibility to change the behaviour of loading the conftest.py's? Are you using the latest 1.3.1 version? It is meant to call the funcarg factory defined in the closest conftest.py file as seen from the test file. IOW, if you have a/conftest.py b/conftest.py then a/test_1.py and b/test_1.py should use the respective factories in the conftest files. If you experience different behaviour i'd consider it a bug and would kindly ask you to submit a more detailed example. best, holger From holger at merlinux.eu Fri Jun 25 10:55:03 2010 From: holger at merlinux.eu (holger krekel) Date: Fri, 25 Jun 2010 10:55:03 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <4C246640.8030508@gmx.de> References: <20100624143559.234190@gmx.net> <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> Message-ID: <20100625085503.GG14601@trillke.net> Hi Frank, On Fri, Jun 25, 2010 at 10:18 +0200, Frank Hempel wrote: > Hi Holger, > > thank you for the immediate reply. > > Am 24.06.2010 16:40, schrieb holger krekel: > > Are you using the latest 1.3.1 version? It is meant to call the funcarg > > Shame on me. I used 1.0.2. > Indeed with 1.3.1 the nearest funcarg factories are called. Perfect. good. > There is just one little thing left where i'm not sure what the benefit > is in it. Consider the dir structure as meant in the last mails: > > a/conftest.py > b/conftest.py > > If py.test is started from within the "a"-directory not only the > conftest.py's of parent directories of "a" are loaded (as stated in the > docs), also the conftest.py of the "b"-directory is loaded. I > intuitively wouldn't consider "b" a parent of "a". Also the tests from > "b" are not run of course. Does it makes sense to load "b"'s conftest.py > too in this situation? I agree it's a bit suprising. I'll explain why also to clarify it for myself :) * py.test sees the command line arg b/test_hello.py * it performs collection starting from the directory where 'b' is contained, call it ROOTDIR * collecting ROOTDIR will collect all matching subdirs and files, so 'a' and 'b' * [HERE] collecting the 'b' subdir will consult b/conftest.py to allow it to influence the directory collection objects (it will call the pytest_collect_directory(...) hook to be precise) * after all subdirs/files have been collected the one matching the name 'b' is dived into * ... I think [HERE] is the issue: we could say that a conftest.py cannot determine the directory collection object of its containing directory (only of the subdirs) so for collecting 'b' the conftest.py would not need to be loaded. It's an edge case and so far i have been wary to change it for backward-compat reasons. However, i'd like to try to get rid of the py.test.collect.Directory subclass customization possibility alltogether and rather provide a simple hook which directly implements directory collection, it would simplify internal code and as a side effect remove the surprise you encountered. (because no attempt to collect anything under 'b' would be made and thus no a/conftest.py consulted when calling py.test on 'a') best, holger From holger at merlinux.eu Fri Jun 25 10:59:00 2010 From: holger at merlinux.eu (holger krekel) Date: Fri, 25 Jun 2010 10:59:00 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <20100625085503.GG14601@trillke.net> References: <20100624143559.234190@gmx.net> <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> Message-ID: <20100625085900.GH14601@trillke.net> On Fri, Jun 25, 2010 at 10:55 +0200, holger krekel wrote: > However, i'd like to try to get rid of the py.test.collect.Directory subclass customization > possibility alltogether and rather provide a simple hook which directly implements directory > collection, it would simplify internal code and as a side effect remove the surprise you encountered. > (because no attempt to collect anything under 'b' would be made and thus no a/conftest.py consulted > when calling py.test on 'a') um, ... fixed: because no attempt to collect anything under 'b' would be made and thus no b/conftest.py consulted when calling py.test on 'a' all those little a's and b's :) holger From red_socks at gmx.de Fri Jun 25 11:44:18 2010 From: red_socks at gmx.de (Frank Hempel) Date: Fri, 25 Jun 2010 11:44:18 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <20100625085503.GG14601@trillke.net> References: <20100624143559.234190@gmx.net> <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> Message-ID: <4C247A72.3060903@gmx.de> Am 25.06.2010 10:55, schrieb holger krekel: >> There is just one little thing left where i'm not sure what the benefit >> is in it. Consider the dir structure as meant in the last mails: >> >> a/conftest.py >> b/conftest.py >> >> If py.test is started from within the "a"-directory not only the >> conftest.py's of parent directories of "a" are loaded (as stated in the >> docs), also the conftest.py of the "b"-directory is loaded. I >> intuitively wouldn't consider "b" a parent of "a". Also the tests from >> "b" are not run of course. Does it makes sense to load "b"'s conftest.py >> too in this situation? > > I agree it's a bit suprising. I'll explain why also to clarify it for myself :) > > * py.test sees the command line arg b/test_hello.py > * it performs collection starting from the directory where 'b' is contained, call it ROOTDIR > * collecting ROOTDIR will collect all matching subdirs and files, so 'a' and 'b' > * [HERE] collecting the 'b' subdir will consult b/conftest.py to allow it to influence the > directory collection objects (it will call the pytest_collect_directory(...) hook to be precise) > * after all subdirs/files have been collected the one matching the name 'b' is dived into > * ... This process I was expecting when calling "py.test" (without arguments or with 'b/test_hello.py') from the ROOTDIR, as i think in your explaination you meant having py.test being called from ROOTDIR because the argument 'b/test_hello.py' you mentioned has 'b/' in it, right?. When calling py.test (without arguments or 'test_hello.py') from within the 'b'-directory i would expect that the collecting will only be done for that 'b'-directory and its child directories. To make sure we are talking about the same a's and b's ;) the dir structure is: ~/ROOTDIR/ a/ conftest.py test_hello.py b/ contest.py test_hello.py on the cmd line i do: ~$ cd ROOTDIR/b ~/ROOTDIR/b$ py.test ================ test session starts ================ platform linux2 -- Python 2.5.5 -- pytest-1.3.1 test object 1: ~/ROOTDIR/b test_hello.py . ============= 1 passed in 0.01 seconds ============== if both conftest.py's have a pytest_configure and pytest_unconfigure, they will be called in this order: configure of b configure of a unconfigure of a unconfigure of b I agree that both 'a' and 'b' should be inspected when calling py.test from ROOTDIR, but when calling it within 'a' or 'b'...? ...i hope i don't bother you if i misunderstood your explaination (sorry in that case). but that you wrote "* py.test sees the command line arg b/test_hello.py" made me wonder whether you misunderstood me in the way that you thought i meant calling py.test from ROOTDIR. Thank you, Best regards, Frank From holger at merlinux.eu Fri Jun 25 12:05:36 2010 From: holger at merlinux.eu (holger krekel) Date: Fri, 25 Jun 2010 12:05:36 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <4C247A72.3060903@gmx.de> References: <20100624143559.234190@gmx.net> <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> <4C247A72.3060903@gmx.de> Message-ID: <20100625100535.GI14601@trillke.net> On Fri, Jun 25, 2010 at 11:44 +0200, Frank Hempel wrote: > Am 25.06.2010 10:55, schrieb holger krekel: > >> There is just one little thing left where i'm not sure what the benefit > >> is in it. Consider the dir structure as meant in the last mails: > >> > >> a/conftest.py > >> b/conftest.py > >> > >> If py.test is started from within the "a"-directory not only the > >> conftest.py's of parent directories of "a" are loaded (as stated in the > >> docs), also the conftest.py of the "b"-directory is loaded. I > >> intuitively wouldn't consider "b" a parent of "a". Also the tests from > >> "b" are not run of course. Does it makes sense to load "b"'s conftest.py > >> too in this situation? > > > > I agree it's a bit suprising. I'll explain why also to clarify it for myself :) > > > > * py.test sees the command line arg b/test_hello.py > > * it performs collection starting from the directory where 'b' is contained, call it ROOTDIR > > * collecting ROOTDIR will collect all matching subdirs and files, so 'a' and 'b' > > * [HERE] collecting the 'b' subdir will consult b/conftest.py to allow it to influence the > > directory collection objects (it will call the pytest_collect_directory(...) hook to be precise) > > * after all subdirs/files have been collected the one matching the name 'b' is dived into > > * ... > > This process I was expecting when calling "py.test" (without arguments > or with 'b/test_hello.py') from the ROOTDIR, as i think in your > explaination you meant having py.test being called from ROOTDIR because > the argument 'b/test_hello.py' you mentioned has 'b/' in it, right?. I understand the confusion but indeed, i really meant py.test b/test_hello.py will cause a collection of the ROOTDIR (containing 'b' and 'a'). py.test always collects from the root now matter how you call it. Otherwise collection customizations would not work uniformly. If you call py.test --collectonly you can see the collection result, btw. > ... > if both conftest.py's have a pytest_configure and pytest_unconfigure, > they will be called in this order: > > configure of b > configure of a > unconfigure of a > unconfigure of b > > I agree that both 'a' and 'b' should be inspected when calling py.test > from ROOTDIR, but when calling it within 'a' or 'b'...? I understand your surprise which is why i told the background story and how i'd like to fix it. > ...i hope i don't bother you if i misunderstood your explaination (sorry > in that case). but that you wrote "* py.test sees the command line arg > b/test_hello.py" made me wonder whether you misunderstood me in the way > that you thought i meant calling py.test from ROOTDIR. you are welcome and thanks for trying to clarify. best, holger From red_socks at gmx.de Fri Jun 25 13:05:34 2010 From: red_socks at gmx.de (Frank Hempel) Date: Fri, 25 Jun 2010 13:05:34 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <20100625100535.GI14601@trillke.net> References: <20100624143559.234190@gmx.net> <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> <4C247A72.3060903@gmx.de> <20100625100535.GI14601@trillke.net> Message-ID: <4C248D7E.70104@gmx.de> Am 25.06.2010 12:05, schrieb holger krekel: > > I understand the confusion but indeed, i really meant > > py.test b/test_hello.py > > will cause a collection of the ROOTDIR (containing 'b' and 'a'). > py.test always collects from the root now matter how you call it. This backs with my expectations. This means for our play-case: No matter whether I execute ~/ROOTDIR$ py.test or ~/ROOTDIR$ py.test b/test_hello.py it always inspects 'a' and 'b'. That's ok. But my concern is not about how i call it (from ROOTDIR) but _from_ _where_ i call it. Because when i enter the 'b' directory and doing ~/ROOTDIR/b$ py.test it will still examine ~/ROOTDIR/a. By the way ROOTDIR does not contain a __init__.py in this example, what at first I guessed would be the cause to let py.test take all neighbor directories into account. What i found out is, that py.test walks up one directory from where it was started and then examines the directories found regardless whether if found __init__.py on that upper level or not. Only the walking up stops when there is no __init__.py found, but the last walk-up step (or the first step where no __init__.py was found) is still used for collecting. Another example: ~/ROOTDIR/ a/ __init__.py c/ test_hello.py b/ conftest.py and I change dir to ~/ROOTDIR/a/c and call py.test from there. Then it walks from 'c' up to 'a', looking for a __init__.py. Because it found one then it walks up to ROOTDIR, does not find __init__.py there, but nevertheless takes 'b' into consideration. If we remove a/__init__.py and call py.test from ~ROOTDIR/a/c again then it only walks from 'c' up to 'a', does not find __init__.py and stops walking up. So the point what makes me surprise is, that the collection process takes directories from an upper dir-level into account even when there was no __init__.py found on that level. I hope I could make my concern clearer now. Thanks, Regards, Frank From red_socks at gmx.de Fri Jun 25 13:43:33 2010 From: red_socks at gmx.de (Frank Hempel) Date: Fri, 25 Jun 2010 13:43:33 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <4C248D7E.70104@gmx.de> References: <20100624143559.234190@gmx.net> <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> <4C247A72.3060903@gmx.de> <20100625100535.GI14601@trillke.net> <4C248D7E.70104@gmx.de> Message-ID: <4C249665.7070700@gmx.de> Am 25.06.2010 13:05, schrieb Frank Hempel: > ... > there is no __init__.py found, but the last walk-up step (or the first > step where no __init__.py was found) is still used for collecting. ...'collecting' was the wrong word. I meant examination which is loading of conftest.py. Tests are not collected of course. Regards, Frank From jgustak at gmail.com Fri Jun 25 16:10:08 2010 From: jgustak at gmail.com (Jakub Gustak) Date: Fri, 25 Jun 2010 15:10:08 +0100 Subject: [py-dev] adding env option to xspec (initialy posted to [execnet-dev]) Message-ID: > Hi Jakub, > > not sure it makes sense to add this to execnet, maybe better > to xdist code? ?Things is it's easy to set environment variables > when initializing gateways yourself. Just when using pytest-xdist > you cannot easily do this because that API level is not exposed. > So xdist could grow a configuration option to interpret > some additional xspec settings. > > I suggest to use > > ? ?popen//env:NAME=value > > as syntax. ? That being said i am not totally opposed to adding > it directly to execnet. ?Maybe other people here on the list also > have comments ... > > best, > holger > > On Thu, Jun 24, 2010 at 13:30 +0100, Jakub Gustak wrote: >> Hello, >> >> I need to specify some ENV variable when running a sub-process (this >> case for xdist). AFAIK there is no support for such feature. >> >> I do a workaround by popen//python=./python_with_env where >> ./python_with_env does specify required ENV. >> >> It would be nice to have xspec env option (e.g. popen//env='VAR1=value >> VAR2=value' ). >> >> I can fry up a patch for this functionality if you consider it a >> feature worth inclusion. >> >> Cheers, >> Jakub Gustak Moving this topic to py-dev list in this case. I prepared a patch, please review. What I don't like about it is using XSspec.__dict__ because env:NAME=VALUE requires a iteration through XSpec attributes: + def env(self): + return [(env.lstrip('env:'), value) + for env, value in self.gateway.spec.__dict__.iteritems() + if env.startswith('env:')] I believe a small extension to XSpec API would be nice. Any other ideas? regards, jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: env_xspec.patch Type: application/octet-stream Size: 3570 bytes Desc: not available URL: From holger at merlinux.eu Fri Jun 25 16:19:08 2010 From: holger at merlinux.eu (holger krekel) Date: Fri, 25 Jun 2010 16:19:08 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <4C248D7E.70104@gmx.de> References: <20100624143559.234190@gmx.net> <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> <4C247A72.3060903@gmx.de> <20100625100535.GI14601@trillke.net> <4C248D7E.70104@gmx.de> Message-ID: <20100625141908.GJ14601@trillke.net> On Fri, Jun 25, 2010 at 13:05 +0200, Frank Hempel wrote: > Am 25.06.2010 12:05, schrieb holger krekel: > > > > I understand the confusion but indeed, i really meant > > > > py.test b/test_hello.py > > > > will cause a collection of the ROOTDIR (containing 'b' and 'a'). > > py.test always collects from the root now matter how you call it. > > This backs with my expectations. This means for our play-case: No matter > whether I execute > ~/ROOTDIR$ py.test > or > ~/ROOTDIR$ py.test b/test_hello.py > it always inspects 'a' and 'b'. That's ok. > > But my concern is not about how i call it (from ROOTDIR) but _from_ > _where_ i call it. It is basically equivalent if you have a CWD of 'b' and call "py.test" or if you are one dir up and call "py.test b". This is what i meant with "no matter how you call it". > Because when i enter the 'b' directory and doing > ~/ROOTDIR/b$ py.test > it will still examine ~/ROOTDIR/a. By the way ROOTDIR does not contain a > __init__.py in this example, what at first I guessed would be the cause > to let py.test take all neighbor directories into account. What i found > out is, that py.test walks up one directory from where it was started > and then examines the directories found regardless whether if found > __init__.py on that upper level or not. Only the walking up stops when > there is no __init__.py found, but the last walk-up step (or the first > step where no __init__.py was found) is still used for collecting. Yes, it's true and documented here (only indirectly though): http://codespeak.net/py/dist/test/customize.html#id22 > Another example: > > ~/ROOTDIR/ > a/ > __init__.py > c/ > test_hello.py > b/ > conftest.py > > and I change dir to ~/ROOTDIR/a/c and call py.test from there. Then it > walks from 'c' up to 'a', looking for a __init__.py. Because it found > one then it walks up to ROOTDIR, does not find __init__.py there, but > nevertheless takes 'b' into consideration. If we remove a/__init__.py > and call py.test from ~ROOTDIR/a/c again then it only walks from 'c' up > to 'a', does not find __init__.py and stops walking up. Yes, what you are seeing is the algorithm behind finding the ROOTDIR. > So the point what makes me surprise is, that the collection process > takes directories from an upper dir-level into account even when there > was no __init__.py found on that level. It internally needs to perform a collection on the ROOTDIR in order to "select" 'a'. In fact, the reason behind all this is that py.test tries to construct a *canonical* collection tree up to the command line specified argument and this three starts from the ROOTDIR / root node which is indeed determined as the last non-init-containing directory. > I hope I could make my concern clearer now. I think so - your analysis is right - i guess i didn't succeed yet in explaining the logic/reasoning behind the current behaviour, hope it's clearer now. best, holger From holger at merlinux.eu Fri Jun 25 16:41:06 2010 From: holger at merlinux.eu (holger krekel) Date: Fri, 25 Jun 2010 16:41:06 +0200 Subject: [py-dev] adding env option to xspec (initialy posted to [execnet-dev]) In-Reply-To: References: Message-ID: <20100625144105.GK14601@trillke.net> Hi Jakub, On Fri, Jun 25, 2010 at 15:10 +0100, Jakub Gustak wrote: > > I suggest to use > > > > ? ?popen//env:NAME=value > > > > as syntax. ? That being said i am not totally opposed to adding > > it directly to execnet. ?Maybe other people here on the list also > > have comments ... > ... > Moving this topic to py-dev list in this case. > > I prepared a patch, please review. > > What I don't like about it is using XSspec.__dict__ because > env:NAME=VALUE requires a iteration through XSpec attributes: > > + def env(self): > + return [(env.lstrip('env:'), value) > + for env, value in self.gateway.spec.__dict__.iteritems() > + if env.startswith('env:')] > > I believe a small extension to XSpec API would be nice. Any other ideas? I think this is bearable as xspecs have very few key-value pairs. You could use env[4:] instead of lstrip() to optimize though :) One other bit: could you try to rework your patch so that it transfers the environment variables in the "slaveinput" dictionary? This is also processable from pytest_configure and produces a smaller patch i guess. best, holger From jgustak at gmail.com Fri Jun 25 17:05:01 2010 From: jgustak at gmail.com (Jakub Gustak) Date: Fri, 25 Jun 2010 16:05:01 +0100 Subject: [py-dev] adding env option to xspec (initialy posted to [execnet-dev]) In-Reply-To: <20100625144105.GK14601@trillke.net> References: <20100625144105.GK14601@trillke.net> Message-ID: On Fri, Jun 25, 2010 at 3:41 PM, holger krekel wrote: > Hi Jakub, > > On Fri, Jun 25, 2010 at 15:10 +0100, Jakub Gustak wrote: >> > I suggest to use >> > >> > ? ?popen//env:NAME=value >> > >> > as syntax. ? That being said i am not totally opposed to adding >> > it directly to execnet. ?Maybe other people here on the list also >> > have comments ... >> ... >> Moving this topic to py-dev list in this case. >> >> I prepared a patch, please review. >> >> What I don't like about it is using XSspec.__dict__ because >> env:NAME=VALUE requires a iteration through XSpec attributes: >> >> + ? ?def env(self): >> + ? ? ? ?return [(env.lstrip('env:'), value) >> + ? ? ? ? ? ? ? ? ? ?for env, value in ?self.gateway.spec.__dict__.iteritems() >> + ? ? ? ? ? ? ? ? ? ?if env.startswith('env:')] >> >> I believe a small extension to XSpec API would be nice. Any other ideas? > > I think this is bearable as xspecs have very few key-value pairs. > You could use env[4:] instead of lstrip() to optimize though :) > > One other bit: could you try to rework your patch so that it transfers > the environment variables in the "slaveinput" dictionary? > This is also processable from pytest_configure and produces a > smaller patch i guess. Can you explain in more details? Passing in the slaveinput is not a problem, but where you would like the environ be updated exactly? jakub From holger at merlinux.eu Fri Jun 25 17:56:19 2010 From: holger at merlinux.eu (holger krekel) Date: Fri, 25 Jun 2010 17:56:19 +0200 Subject: [py-dev] adding env option to xspec (initialy posted to [execnet-dev]) In-Reply-To: References: <20100625144105.GK14601@trillke.net> Message-ID: <20100625155619.GL14601@trillke.net> On Fri, Jun 25, 2010 at 16:05 +0100, Jakub Gustak wrote: > > One other bit: could you try to rework your patch so that it transfers > > the environment variables in the "slaveinput" dictionary? > > This is also processable from pytest_configure and produces a > > smaller patch i guess. > > Can you explain in more details? > > Passing in the slaveinput is not a problem, but where you would like > the environ be updated exactly? Just like now but taking it from slaveinput['env']. holger From anto.cuni at gmail.com Fri Jun 25 17:58:25 2010 From: anto.cuni at gmail.com (Antonio Cuni) Date: Fri, 25 Jun 2010 17:58:25 +0200 Subject: [py-dev] adding env option to xspec (initialy posted to [execnet-dev]) In-Reply-To: <20100625144105.GK14601@trillke.net> References: <20100625144105.GK14601@trillke.net> Message-ID: <4C24D221.60803@gmail.com> On 25/06/10 16:41, holger krekel wrote: >> > + def env(self): >> > + return [(env.lstrip('env:'), value) >> > + for env, value in self.gateway.spec.__dict__.iteritems() >> > + if env.startswith('env:')] >> > > You could use env[4:] instead of lstrip() to optimize though :) using [:4] instead of lstrip is not much about performance, but about correctness: >>> 'env:env'.lstrip('env:') '' ciao, Anto From red_socks at gmx.de Fri Jun 25 18:02:41 2010 From: red_socks at gmx.de (Frank Hempel) Date: Fri, 25 Jun 2010 18:02:41 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <20100625141908.GJ14601@trillke.net> References: <20100624143559.234190@gmx.net> <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> <4C247A72.3060903@gmx.de> <20100625100535.GI14601@trillke.net> <4C248D7E.70104@gmx.de> <20100625141908.GJ14601@trillke.net> Message-ID: <4C24D321.7090804@gmx.de> Am 25.06.2010 16:19, schrieb holger krekel: > > It internally needs to perform a collection on the ROOTDIR > in order to "select" 'a'. In fact, the reason behind all this is that > py.test tries to construct a *canonical* collection tree up to the command > line specified argument and this three starts from the ROOTDIR / root node > which is indeed determined as the last non-init-containing directory. > >> I hope I could make my concern clearer now. > > I think so - your analysis is right - i guess i didn't succeed yet in > explaining the logic/reasoning behind the current behaviour, hope it's > clearer now. Ok. Thanks so far for taking the time and explaining this. Nevertheless i'm not absolutely happy with the situation that all directories of the "first non-init-containing directory" (should be called first, right?) are considered for conftest-loading. Because without changing anything to one's project 'a' it can make a difference in the sense of tests passing or failing for the project 'a' in dependency of what other project folders one puts side-by-side to 'a'. One not too unlikely side effect could be: the pytest_configure function of each conftest.py (the one of folder 'a' and of 'b') sets something to sys.path with a commonly used statement like "sys.path.insert(*0*, ...)". When testing project 'a' and with the fact that the order of the conftest-loadings is that "b"'s will be loaded after "a"'s, the sys.path.insertion of 'b' will take precedence. Regardless of the fact the the project 'b' might have have nothing to do with project 'a', it just sits side-by-side in the filesystem. And i'm actually not complaining th order. For my expectaion "b"'s conftest should not be loaded at all if i'm testing 'a' and the containing directory of 'a' and 'b' does not contain an __init__.py. ...do you agree with that :) ? Thanks again, Best regards, Frank > > best, > holger From jgustak at gmail.com Fri Jun 25 18:36:45 2010 From: jgustak at gmail.com (Jakub Gustak) Date: Fri, 25 Jun 2010 17:36:45 +0100 Subject: [py-dev] adding env option to xspec (initialy posted to [execnet-dev]) In-Reply-To: <4C24D221.60803@gmail.com> References: <20100625144105.GK14601@trillke.net> <4C24D221.60803@gmail.com> Message-ID: >>> > ?+ ? ?def env(self): >>> > ?+ ? ? ? ?return [(env.lstrip('env:'), value) >>> > ?+ ? ? ? ? ? ? ? ? ? ?for env, value in >>> > ?self.gateway.spec.__dict__.iteritems() >>> > ?+ ? ? ? ? ? ? ? ? ? ?if env.startswith('env:')] >>> > > >> You could use env[4:] instead of lstrip() to optimize though :) > > > using [:4] instead of lstrip is not much about performance, but about > correctness: > >>>> 'env:env'.lstrip('env:') > '' True, I somehow forgot strip removes chars not whole string. _ jakub From jgustak at gmail.com Fri Jun 25 18:29:58 2010 From: jgustak at gmail.com (Jakub Gustak) Date: Fri, 25 Jun 2010 17:29:58 +0100 Subject: [py-dev] adding env option to xspec (initialy posted to [execnet-dev]) In-Reply-To: <20100625155619.GL14601@trillke.net> References: <20100625144105.GK14601@trillke.net> <20100625155619.GL14601@trillke.net> Message-ID: On Fri, Jun 25, 2010 at 4:56 PM, holger krekel wrote: > On Fri, Jun 25, 2010 at 16:05 +0100, Jakub Gustak wrote: >> > One other bit: could you try to rework your patch so that it transfers >> > the environment variables in the "slaveinput" dictionary? >> > This is also processable from pytest_configure and produces a >> > smaller patch i guess. >> >> Can you explain in more details? >> >> Passing in the slaveinput is not a problem, but where you would like >> the environ be updated exactly? > > Just like now but taking it from slaveinput['env']. > > holger > There we go! _ jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: env_xspec.patch Type: application/octet-stream Size: 3044 bytes Desc: not available URL: From holger at merlinux.eu Fri Jun 25 19:08:36 2010 From: holger at merlinux.eu (holger krekel) Date: Fri, 25 Jun 2010 19:08:36 +0200 Subject: [py-dev] adding env option to xspec (initialy posted to [execnet-dev]) In-Reply-To: References: <20100625144105.GK14601@trillke.net> <20100625155619.GL14601@trillke.net> Message-ID: <20100625170836.GM14601@trillke.net> On Fri, Jun 25, 2010 at 17:29 +0100, Jakub Gustak wrote: > On Fri, Jun 25, 2010 at 4:56 PM, holger krekel wrote: > > On Fri, Jun 25, 2010 at 16:05 +0100, Jakub Gustak wrote: > >> > One other bit: could you try to rework your patch so that it transfers > >> > the environment variables in the "slaveinput" dictionary? > >> > This is also processable from pytest_configure and produces a > >> > smaller patch i guess. > >> > >> Can you explain in more details? > >> > >> Passing in the slaveinput is not a problem, but where you would like > >> the environ be updated exactly? > > > > Just like now but taking it from slaveinput['env']. > > > > holger > > > > There we go! did you run the tests? they fail for me. holger From holger at merlinux.eu Fri Jun 25 19:11:15 2010 From: holger at merlinux.eu (holger krekel) Date: Fri, 25 Jun 2010 19:11:15 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <4C24D321.7090804@gmx.de> References: <20100624143559.234190@gmx.net> <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> <4C247A72.3060903@gmx.de> <20100625100535.GI14601@trillke.net> <4C248D7E.70104@gmx.de> <20100625141908.GJ14601@trillke.net> <4C24D321.7090804@gmx.de> Message-ID: <20100625171115.GN14601@trillke.net> On Fri, Jun 25, 2010 at 18:02 +0200, Frank Hempel wrote: > Am 25.06.2010 16:19, schrieb holger krekel: > > > > It internally needs to perform a collection on the ROOTDIR > > in order to "select" 'a'. In fact, the reason behind all this is that > > py.test tries to construct a *canonical* collection tree up to the command > > line specified argument and this three starts from the ROOTDIR / root node > > which is indeed determined as the last non-init-containing directory. > > > >> I hope I could make my concern clearer now. > > > > I think so - your analysis is right - i guess i didn't succeed yet in > > explaining the logic/reasoning behind the current behaviour, hope it's > > clearer now. > > Ok. Thanks so far for taking the time and explaining this. > > Nevertheless i'm not absolutely happy with the situation that all > directories of the "first non-init-containing directory" (should be > called first, right?) are considered for conftest-loading. > Because without changing anything to one's project 'a' it can make a > difference in the sense of tests passing or failing for the project 'a' > in dependency of what other project folders one puts side-by-side to 'a'. > One not too unlikely side effect could be: the pytest_configure function > of each conftest.py (the one of folder 'a' and of 'b') sets something to > sys.path with a commonly used statement like "sys.path.insert(*0*, > ...)". When testing project 'a' and with the fact that the order of the > conftest-loadings is that "b"'s will be loaded after "a"'s, the > sys.path.insertion of 'b' will take precedence. Regardless of the fact > the the project 'b' might have have nothing to do with project 'a', it > just sits side-by-side in the filesystem. And i'm actually not > complaining th order. For my expectaion "b"'s conftest should not be > loaded at all if i'm testing 'a' and the containing directory of 'a' and > 'b' does not contain an __init__.py. > > ...do you agree with that :) ? Somewhat although i consider it bad practise to do sys.path manipulations in pytest_configure. It probably also means that you can get trouble when you run things from the root dir and both the 'a' and 'b' tests are run. Anyway, i agree it'd be nicer if py.test would not implicitely load the sibling directory's conftest.py. Could you care to file an "enhancement" issue in the bitbucket tracker? If you add a test case that you'd like to work that'd be good. I am not sure i fix it for the soon upcoming minor release but i definitely give it a try for 1.4. best, holger From red_socks at gmx.de Fri Jun 25 19:28:15 2010 From: red_socks at gmx.de (Frank Hempel) Date: Fri, 25 Jun 2010 19:28:15 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <20100625171115.GN14601@trillke.net> References: <20100624143559.234190@gmx.net> <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> <4C247A72.3060903@gmx.de> <20100625100535.GI14601@trillke.net> <4C248D7E.70104@gmx.de> <20100625141908.GJ14601@trillke.net> <4C24D321.7090804@gmx.de> <20100625171115.GN14601@trillke.net> Message-ID: <4C24E72F.3080802@gmx.de> Am 25.06.2010 19:11, schrieb holger krekel: > On Fri, Jun 25, 2010 at 18:02 +0200, Frank Hempel wrote: >> Am 25.06.2010 16:19, schrieb holger krekel: > > Somewhat although i consider it bad practise to do sys.path manipulations > in pytest_configure. It probably also means that you can get trouble when > you run things from the root dir and both the 'a' and 'b' tests are run. I agree with your opinion. I just could not get something more stupid into mind... ;) > Anyway, i agree it'd be nicer if py.test would not implicitely load the > sibling directory's conftest.py. Could you care to file an "enhancement" > issue in the bitbucket tracker? If you add a test case that you'd like to > work that'd be good. I am not sure i fix it for the soon upcoming minor > release but i definitely give it a try for 1.4. I will do that. Thank's for your agreement :) Best Regards, Frank From jgustak at gmail.com Sat Jun 26 09:55:52 2010 From: jgustak at gmail.com (Jakub Gustak) Date: Sat, 26 Jun 2010 08:55:52 +0100 Subject: [py-dev] adding env option to xspec (initialy posted to [execnet-dev]) In-Reply-To: <20100625170836.GM14601@trillke.net> References: <20100625144105.GK14601@trillke.net> <20100625155619.GL14601@trillke.net> <20100625170836.GM14601@trillke.net> Message-ID: > did you run the tests? they fail for me. With this patch the tests are passing. Also I found out nice interesting thing. To test those changes I have to use the same xdist version (e.g installed setup.py develope) for testing. This is interesting paradox. How do you setup your development environment properly? _ jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: env_xspec.patch Type: text/x-patch Size: 3049 bytes Desc: not available URL: From issues-noreply at bitbucket.org Sat Jun 26 19:44:58 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sat, 26 Jun 2010 17:44:58 -0000 Subject: [py-dev] New issue 108 in py-trunk: Warnings should be acknowledged somehow Message-ID: <8499fc8451598dc5c125f691fcb97ee0@bitbucket.org> --- you can reply above this line --- New issue 108: Warnings should be acknowledged somehow http://bitbucket.org/hpk42/py-trunk/issue/108/warnings-should-be-acknowledged-somehow inducer on Sat, 26 Jun 2010 19:44:58 +0200: Description: Sometimes one detects a condition that should be fixed, but is not severe enough to warrant failing a test altogether. One such example are warnings reported through Python's warnings module. So far, these get swallowed up by py.test. I would argue that they should be reported somehow. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From issues-noreply at bitbucket.org Sun Jun 27 14:03:15 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sun, 27 Jun 2010 12:03:15 -0000 Subject: [py-dev] New issue 109 in py-trunk: implicit loading of sibling directory's conftest.py Message-ID: <977e5b7304223f4592389013670f0331@bitbucket.org> --- you can reply above this line --- New issue 109: implicit loading of sibling directory's conftest.py http://bitbucket.org/hpk42/py-trunk/issue/109/implicit-loading-of-sibling-directorys Anonymous on Sun, 27 Jun 2010 14:03:15 +0200: Description: As discussed on the mailing list (subject: funcarg name clash / conftest load behaviour) it would be nice if py.test does not implicitely load the sibling directory's conftest.py in case those directories are not packaged with an __init__.py. Consider the directory structure: ROOTDIR/ a/ conftest.py test_hello.py b/ conftest.py test_hello.py Calling py.test from ROOTDIR with argument 'a' (or from ROOTDIR/a without args) should not load b/conftest.py. The applied patch against py-1.3.1 adds a test case for this situation. I have to say that I'm not sure whether the location is best and things in it might be done better, because this was the fist time I'm in touch with the code. Best regards, Frank -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.