Mailman 3 February 2015 - pytest-dev

Crowdfunding a pytest plugin
by Tibor Arpas March 13, 2015

March 13, 2015

Hello pytesters, We are putting together a small Indiegogo campaign for a pytest plugin which should significantly improve the experience of executing a long test suite. We'd be glad to hear any feedback before launching it. The draft is here: https://www.indiegogo.com/project/preview/4fe07d66 Also, is anybody interested in helping with promotion and/or development? Cheers, Tibor

4 6

Enabling viewing of rewritten AST trees as Python
by Tom Viner March 2, 2015

March 2, 2015

Hi, In the process of fixing a recent bug <https://bitbucket.org/hpk42/pytest/issue/615/valueerror-on-compound-assert-…> in pytest source rewriting I found a library to take the rewritten AST tree and generate Python source code from it. Floris mentioned this could be helpful to pytest developers working on the assertion rewriting code. The library is called Meta <https://pypi.python.org/pypi/meta>. (Note, currently only the develop branch on github works successfully on pytest's rewrite tests.) It allows viewing an AST tree as Python source with a single call: import meta log.debug(meta.asttools.dump_python_source(ast_tree)) The question I have: how can pytest developers (and those debugging pytest's rewriting of their tests) best get access to the rewritten AST tree, to be able to view it's Python source representation? The AST tree is seen in pytest/_pytest/assertion/rewrite.py::rewrite_asserts <https://bitbucket.org/hpk42/pytest/src/default/_pytest/assertion/rewrite.py…> in the mod variable: def rewrite_asserts(mod): """Rewrite the assert statements in mod.""" AssertionRewriter().run(mod) The four options I can think of to gain access to this variable: - monkey patch rewrite.rewrite_asserts - edit rewrite_asserts and paste in the logging code above: -- temporarily, by each developer, on each occasion required -- permanently, but only running when a certain debug flag is active - expose the rewritten AST via a new hook monkey patch is my preferred option, because if I can make it work, a plugin could be written. I just need some help to find an appropriate hook to do the monkey patching before pytest gets going with the AssertionRewritingHook and calls rewrite_asserts. Without knowledge of an early-running hook, I could only get this working by patching rewrite_asserts then calling pytest.main myself, see https://gist.github.com/tomviner/13c95cdb1e159028fc0b Second option, I could explain how to do the temporary edit in a short blog post. This would get past the pytest.main downside to the gist above. But telling people to edit random pytest source files seems bad form. Third option, a pull request on pytest logging the Python source, only if a debug flag is active and Meta is importable. But is this reasonable just for debugging purposes? Alternatively, fourth, a new hook could be added to expose the rewritten AST tree, and everything else could then be a plugin. Thoughts? To see the assertion rewriting pytest does, as Python code, follow the instructions in my gist: https://gist.github.com/tomviner/13c95cdb1e159028fc0b Cheers, Tom

2 3

commit messages from drone
by holger krekel March 2, 2015

March 2, 2015

Is there a configuration where only failures are sent to the list? It's a bit verbose as it stands IMHO. And maybe just the author in the commit should get success mails for a commit. holger On Sat, Feb 28, 2015 at 20:50 +0000, Drone.io Build wrote: > Build was Successful > > Build : https://drone.io/bitbucket.org/pytest-dev/pytest/13 > Project : https://drone.io/bitbucket.org/pytest-dev/pytest > > Repository : https://bitbucket.org/pytest-dev/pytest > Version : 3892:ebe73a63994f > Author : Anatoly Bubenkov <bubenkoff(a)gmail.com> > Branch : plugincompat-move > > Message: > Close branch plugincompat-move > > _______________________________________________ > pytest-commit mailing list > pytest-commit(a)python.org > https://mail.python.org/mailman/listinfo/pytest-commit -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu

2 2

Let's have an "Adopt pytest month"
by Brianna Laugher Feb. 27, 2015

Feb. 27, 2015

Hello, So as Anatoly mentioned in the notes from the FOSDEM mini-meetup [1], we talked about if we were interested in actively trying to increase pytest adoption, ie get more open source/free software projects using it. As we know how great pytest is, it seems a shame that more people don't know as well! I had an idea that we could have a "adopt pytest month": pair knowledgeable pytest users together with interested projects, and help them convert their existing test suite, or start one from scratch if they don't really have any tests yet. Holger liked the idea, so that's a start :) It would also be a good way for us to discover "pain points" for new pytest users, for example which areas need better documentation or examples. I was thinking it could be in April: · February: gather pytest volunteers · March: advertise and ask for projects interested in taking part · April: the actual work · May: survey/write up how it went I imagine that volunteers would commit to spending maybe 2-4 hours a week, for the month. They would probably need to download and install the project, join their mailing list and give advice, maybe write some code such as example tests, conftest options. (Basically: I would not expect you to write all their tests for them!) I don't think you would need to be a pytest super developer or guru. You could even do it as a way of learning something new about pytest yourself. I am happy to try and organise this. I imagine I would do something like this: · Make a short form to gather details about pytest volunteers (e.g. areas of experience/interest) · Make a page to put on the pytest website, with info to advertise to potential projects · Make a short form for projects to apply/register to take part · Pair volunteers and projects together · Survey volunteers and projects after the month is over, write a summary of responses So, IF YOU ARE INTERESTED IN TAKING PART: please reply to the list to say so! Also if you have any questions or suggestions, let me know. Thanks, Brianna [1] https://docs.google.com/document/d/14mbVs_f5UFypPx5vvaW-Vh_8Xq9XBKeoNrA0dR0… -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

8 8

Move plugins to pytest-deb@github: pytest-cpp, pytest-qt, pytest-mock
by Bruno Oliveira Feb. 27, 2015

Feb. 27, 2015

Hi, I would to like to know if there are any objections to move the following plugins to pytest-dev@github organization: https://github.com/nicoddemus/pytest-qt https://github.com/nicoddemus/pytest-cpp https://github.com/nicoddemus/pytest-mock All of those repositories are in PyPI, have an appropriate README, license, continuous integration, etc. It seems people are starting to move plugins that have a good number of users to the pytest-dev organization, so I thought I would move those too. Cheers,

3 4

[RFC] some initial ideas for pylib-2.0
by Ronny Pfannschmidt Feb. 25, 2015

Feb. 25, 2015

Hi all, i'd like to start some very rough planing for pylib 2.0 hoping for some comments main going a bit far things i currently have in mind * kill py.std * kill most of terminalwriter * move code/capture/saferepr to pytest ? * kill svn path (its broken and nobody fixes it) * de-vendorize apipkg/iniparse * kill xml gen * unify errors and the new python3 error hierachy * modernize py.builtin using six, potential api changes where six raises attribute errors * evaluate log, potentially kill? * refactor local path, consider pathlib this is a long term plan -- Ronny

4 5

[py-dev] using tmpdir/monkeypatch/... from non-function scopes
by Tom Viner Feb. 24, 2015

Feb. 24, 2015

Re this thread from 2012: https://mail.python.org/pipermail/pytest-dev/2012-November/002157.html Was there ever any resolution or workaround to using monkeypatch / tmpdir with scopes other than function? Example: @pytest.fixture(scope="module") def something(monkeypatch): ... you get a ScopeMismatchError Thanks, Tom

3 3

[STATUS, RFC, PLANS] development of the copy-in-cache branch
by Ronny Pfannschmidt Feb. 20, 2015

Feb. 20, 2015

Hi , this is a status and a rfc for the copy-in-cache branch. its mostly relevant for the pytest core developers current status: the pytest-cache branch with the --looponfail/--looponchange modes is copyed in and adapted to the codebase futher plan: also include logcapture backward compat plan: * ignore the cache/logcapture plugins as disabled and warn if they are installed * override the --looponfail option to be a callback, setting the lastfailed and looponchange options and allow pytest-xdist to override it (but warn if a xdist of the current series is found, explaining that the new better behaviour is still availiable using the --looponchange option combined with --lf) note: the current idea is, to implement this in a _pytest.deprecation plugin intentionally left out: * the --boxed option - it should eventually be reimplemeted on top of xdist, current xdist does still include it, (i'd prefer a major xdist release droping all features) -- Ronny

2 1

PRs / pytest2.7
by holger krekel Feb. 20, 2015

Feb. 20, 2015

Hi pytest committers, could you help with looking at/merging PRs for pytest? See https://bitbucket.org/hpk42/pytest/pull-requests Getting out pytest-2.7 in the next 1-2 weeks would be good i guess to clear out the backlog. best and thanks! holger

1 0

[discuss] solving the yield test setupstate problem and expanding on it
by Ronny Pfannschmidt Feb. 11, 2015

Feb. 11, 2015

Hi, since i did hit the generator test i started to create a proof of concept on solving it by creating the pytest_pyfunc_interpret_result hook. now instead of running at collect time, generators checks run inline this currently degrades reporting * breaks on first fail * no separate reports per check and it degrades nose support * no generator check setup/teardown while i suppose its possible to extend generator support with teardown in a hackish fashin i think going for a clean solution makes more sense is anyone propperly using these features? onwards i'd like to check how to extend pytest_pyfunc_interpret_result with convenience for asyncio and twisted -- Ronny

2 1