Mailman 3 July 2010 - pytest-dev

[py-dev] tox-0.8 and py.test-1.3.3 released
by holger krekel July 31, 2010

July 31, 2010

Hi, just did a two test tool releases, one for tox and one for py.test. The tox-0.8 release provides fixes and workarounds, see changelog below. The py-1.3.3 release mainly provides fixes for terminal output. best & thanks to the respective feedbackers/helpers, holger What is tox? ---------------------- Tox is a generic test runner, creating virtualenv environments on the fly and executing your test tool of choice. It works conveniently from a developer's terminal as well as from a Continous Integration Server. See http://codespeak.net/tox What is py.test? ---------------------- py.test is an easy-to-learn testing tool with many plugins and features for integration and functional tests in Python. See http://pytest.org for more info. CHANGES tox-0.8 ----------------- - work around a virtualenv limitation which crashes if PYTHONDONTWRITEBYTECODE is set. - run pip/easy installs from the environment log directory, avoids naming clashes between env names and dependencies (thanks ronny) - require a more recent version of py lib - refactor and refine config detection to work from a single file and to detect the case where a python installation overwrote an old one and resulted in a new executable. This invalidates the existing virtualenvironment now. - change all internal source to strip trailing whitespaces Changes py-1.3.3 ---------------------- - fix issue113: assertion representation problem with triple-quoted strings (and possibly other cases) - make conftest loading detect that a conftest file with the same content was already loaded, avoids surprises in nested directory structures which can be produced e.g. by Hudson. It probably removes the need to use --confcutdir in most cases. - fix terminal coloring for win32 (thanks Michael Foord for reporting) - fix weirdness: make terminal width detection work on stdout instead of stdin (thanks Armin Ronacher for reporting) - remove trailing whitespace in all py/text distribution files

1 0

[py-dev] distributed testing fixes (execnet-1.0.8 and a green experiment)
by holger krekel July 30, 2010

July 30, 2010

hi all, see below for one and a half execnet releases which fix some issues that were originally registered as py.test ones, namely rsync issues with symbolic links and permissions. You can do "pip -U execnet" or "pip -U pytest-xdist" to make sure you have the latest of everything. ("easy_install" is fine as well). best, holger ----- Forwarded message from holger krekel <holger(a)merlinux.eu> ----- Date: Sat, 31 Jul 2010 00:34:04 +0200 From: holger krekel <holger(a)merlinux.eu> To: execnet-dev(a)codespeak.net, python announce <python-announce-list(a)python.org> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Subject: [execnet-dev] execnet-1.0.8 and a green experiment I just released execnet-1.0.8, see the Changelog for details, below. What is execnet? --------------------- execnet is a small pure python library that manages distributed code execution across Python versions and host boundaries. It provides a self-bootstrapping share-nothing model with channels to send/receive data messages. It also helps with managing a cluster of (local or remote) processes and comes with tons of examples and API docs: http://codespeak.net/execnet green version of execnet -------------------------------- For those interested i hacked up a green version of execnet which is API-compatible (and less stable) than the "main" version which relies on operating system threads. The green version requires the eventlet library and is thus not fully self-bootstrapping (you need to install eventlet on all remote nodes you want to execute code on). There is no release but you can peruse http://code.google.com/p/execnet-green/source/checkout and "python setup.py develop" to play with it. It will never spawn any operating system threads. Rather remote_exec() will spawn greenlets/micro-threads of which you can easily have a few thousand. It probably only is stable enough for simple scenarios at this point. best, holger Changelog 1.0.8 (compared to 1.0.7): - new ``gateway.remote_exec(func, **kwargs)`` style fo executing a pure function with parameters. The function on the remote side also needs to accept a ``channel`` which allows it to communicate back and forth. Thanks to Ronny Pfannschmidt for implementing it with special kudos to Maciej Fijalkowski for writing a "pure-function" checker so that on Python2.6 onwards non-pure functions will be rejected. - enhance rsyncing to also sync permissions (stat().st_mode) of directories and files. (should also resolve http://bitbucket.org/hpk42/py-trunk/issue/68/) - fix rsyncing of symlinks, thanks to Charles Solar (should also resolve http://bitbucket.org/hpk42/py-trunk/issue/70/) - update internal usage of apipkg to 1.0b6 - remote_exec(module) now makes sure that the linecache is updated before reading and sending the source. thanks Ronny, Matt. - removed all trailing whitespace from source files _______________________________________________ execnet-dev mailing list execnet-dev(a)codespeak.net http://codespeak.net/mailman/listinfo/execnet-dev ----- End forwarded message ----- --

1 0

[py-dev] unittest2 plugin system for python stdlib
by Philippe Fremy July 30, 2010

July 30, 2010

Hi Holger, I don't know if you are following python-dev, but in case not, you definitely need to have a look at this: http://mail.python.org/pipermail/python-dev/2010-July/102526.html http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186 To quote: "As part of the prototype I have been implementing some example plugins (in unittest2/plugins/) so I can develop the mechanism against real rather than imagined use cases. Jason Pellerin, creator of nose, has been providing me with feedback and has been trying it out by porting some of the nose plugins to unittest [1]. His initial comment on the system was "it looks very flexible and clean". ;-)" I am sure that your feedback would be very valuable too, given the extrem pluginness of py.test . cheers, Philippe

3 2

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] Separate pytest_generate_tests for separate test functions?
by meme dough July 29, 2010

July 29, 2010

Hi, I was wondering about the pytest_generate_tests which can make many parameterise test from 1 test function. When I have many tests and I want to parameterise a number of them the pytest_generate_tests function has to have a if metafunc.function == xxx elif metafunc.function == yyy etc. This means a big switch statement on which function it is. It also means that parameterised data for a function may be a long way from it. This can happen easy when have a test module per source module. Are there any ideas maybe for a pytest_generate_tests for each function that needs to be parameterised? Maybe like pytest_generate_tests__myfunc(metafunc) which can create many tests for the test_myfunc ? Just curious if this would be a good idea or not. :)

2 1

[py-dev] New issue 113 in py-trunk: SyntaxError when an assert fails and a triple-quoted string spans lines
by issues-noreply＠bitbucket.org July 23, 2010

July 23, 2010

--- you can reply above this line --- New issue 113: SyntaxError when an assert fails and a triple-quoted string spans lines http://bitbucket.org/hpk42/py-trunk/issue/113/syntaxerror-when-an-assert-fa… Anonymous on Fri, 23 Jul 2010 18:04:40 +0200: Description: {{{ #!python def test_break_pytest(): """ py.test gives "SyntaxError: EOF while scanning triple-quoted string literal" when an assert fails and a triple-quoted string spans lines NB. this does not occur when the the assert succeeds """ assert "" == """ """ }}} -- 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 112 in py-trunk: A way to report failures as soon as they occur, not afterwards
by issues-noreply＠bitbucket.org July 20, 2010

July 20, 2010

--- you can reply above this line --- New issue 112: A way to report failures as soon as they occur, not afterwards http://bitbucket.org/hpk42/py-trunk/issue/112/a-way-to-report-failures-as-s… Anonymous on Tue, 20 Jul 2010 09:59:55 +0200: Description: Now all tests are run and failures reported afterwards, so for a huge test suite, you can't start fixing the first failures, nor you know that this is a critical failure and just stop the test run. It would be nice if you could pass some parameter and get reports interleaved with test runs. It's not the same as "stop on first failure", because tests should keep on running even after reporting a failed test. -- 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 111 in py-trunk: py.test installation instructions bad for windows machines
by issues-noreply＠bitbucket.org July 18, 2010

July 18, 2010

--- you can reply above this line --- New issue 111: py.test installation instructions bad for windows machines http://bitbucket.org/hpk42/py-trunk/issue/111/pytest-installation-instructi… Anonymous on Sun, 18 Jul 2010 21:16:34 +0200: Description: I am referring to these: http://codespeak.net/py/dist/install.html When installing py.test, the main python installation adirectory and Scripts subdir (e.g. "C:\Python2.6\" and "C:\Python2.6\Scripts") must be added to the windows path. This issue is only mentioned in the "troubleshooting" section, which points here: "http://docs.python.org/faq/windows#how-do-i-run-a-python-program-under-wind…". However, this link does not mention the need to add the <python>\Scripts directory, so it really does not help the user at all. On a side note, I think the installation guide is too complicated. Anything that requires more than zero thought and 30 seconds is deterring users who are "shopping" for testing frameworks. -- 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] tox-0.7: fixes, python3-compat, site-packages
by holger krekel July 14, 2010

July 14, 2010

Hi all, thanks to feedback and help from Michael Foord, Sridhar Ratnakumar, Kumar McMillan, Ronny Pfannschmidt and Ralf Schmitt i just released tox-0.7 which includes a couple of fixes, improved Python3 virtualenv support (on non-windows platforms), and a new sitepackages config option that let's you use globally installed packages. See the more detailed changelog below. The web page is here: http://codespeak.net/tox have fun, holger What is Tox? ---------------- TOX as is a virtualenv management and generic test command line tool you can use for: * checking your package installs correctly with different Python versions and interpreters * running your tests in each of the environments, configuring your test tool of choice * acting as a frontend to Continous Integration servers, greatly reducing boilerplate and merging CI and shell-based testing. Changes 0.7 ---------------------- - use virtualenv5 (my own fork of virtualenv3) for now to create python3 environments, fixes a couple of issues and makes tox more likely to work with Python3 (on non-windows environments) - add ``sitepackages`` option for testenv sections so that environments can be created with access to globals (default is not to have access, i.e. create environments with ``--no-site-packages``. - addressing issue4: always prepend venv-path to PATH variable when calling subprocesses - fix issue2: exit with proper non-zero return code if there were errors or test failures. - added unittest2 examples contributed by Michael Foord - only allow 'True' or 'False' for boolean config values (lowercase / uppercase is irrelevant) - recreate virtualenv on changed configurations 0.6 ----------------- - fix OSX related bugs that could cause the caller's environment to get screwed (sorry). tox was using the same file as virtualenv for tracking the Python executable dependency and there also was confusion wrt links. this should be fixed now. - fix long description, thanks Michael Foord 0.5 ----------------- - initial release

1 0

[py-dev] renaming py and py.test, worth it?
by holger krekel July 14, 2010

July 14, 2010

Hi all, every now and then i am thinking about a renaming strategy for the py lib. Main reasons why i want to rename: * "py" is too generic a name * i want to separate py.test and py packages (py.path and other non-py.test bits are used by quite some projects and it makes no sense to enforce installation of py.test scripts) Here is the strategy: (1) rename py to XXlib (XX being any two letters) (2) rename py.test to AAtest (AA being any two letters) (3) provide a script that helps to replace occurences of "import py" etc. (4) maintain and release XXlib and AAtest separately (5) provide a compatibility "py" package that depends on XXlib and AAtest The (4) is actually slightly tricky because with the rename to AAtest the "pytest_*" hooks should be renamed as well. I can imagine to discover both "pytest_" and "AAtest_" hooks for the first releases after the split. Although i'd aim to minimize the pain this split would certainly cause some. What do you think? Worth it? best, holger

3 5