Mailman 3 June 2010 - pytest-dev

Re: [py-dev] funcarg name clash / conftest load behaviour
by holger krekel July 30, 2010

July 30, 2010

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

2 11

[py-dev] New issue 109 in py-trunk: implicit loading of sibling directory's conftest.py
by issues-noreply＠bitbucket.org June 27, 2010

June 27, 2010

--- 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-d… 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.

1 0

[py-dev] New issue 108 in py-trunk: Warnings should be acknowledged somehow
by issues-noreply＠bitbucket.org June 26, 2010

June 26, 2010

--- 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-acknowledg… 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.

1 0

[py-dev] adding env option to xspec (initialy posted to [execnet-dev])
by Jakub Gustak June 26, 2010

June 26, 2010

> 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

3 8

[py-dev] funcarg name clash / conftest load behaviour
by Frank Hempel June 24, 2010

June 24, 2010

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

2 1

[py-dev] New issue 107 in py-trunk: --pdb does not work with import error
by issues-noreply＠bitbucket.org June 16, 2010

June 16, 2010

--- 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… 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.

3 3

[py-dev] py.test talk at DZUG/Dresden?
by holger krekel June 15, 2010

June 15, 2010

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 --

1 0

[py-dev] New issue 106 in py-trunk: multiline statement in import error looks bogus
by issues-noreply＠bitbucket.org June 12, 2010

June 12, 2010

--- 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… 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.

1 0

[py-dev] New issue 105 in py-trunk: Internal TypeError when assert is on a line with multiple commands and the assertion fails
by issues-noreply＠bitbucket.org June 9, 2010

June 9, 2010

--- 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-asser… 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.

1 0

[py-dev] pytest-cov options
by meme dough June 9, 2010

June 9, 2010

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. :)

2 1