From flub at devork.be  Fri Oct  1 01:23:20 2010
From: flub at devork.be (Floris Bruynooghe)
Date: Fri, 1 Oct 2010 00:23:20 +0100
Subject: [py-dev] controlling assertions and difflib
In-Reply-To: <20100929132818.GK20695@trillke.net>
References: <AANLkTimf7aY-BczSSVvfKFcNvD5BTz6bpE67OEsWyXjM@mail.gmail.com>
	<20100929132818.GK20695@trillke.net>
Message-ID: <AANLkTinY-2_d5+RqhEJ0dGXmY=PFJHwc_opQi=P-2OL5@mail.gmail.com>

Hello

On 29 September 2010 14:28, holger krekel <holger at merlinux.eu> wrote:
> On Wed, Sep 29, 2010 at 00:12 +0100, Floris Bruynooghe wrote:
>> ______________________________ test_hang_in_diff _______________________________
>> /tmp/sandbox/test_bugs.py:4: in test_hang_in_diff
>> > ? ? ? assert x == y
>> E ? ? ? assert '1\n1\n1\n1\n...n2\n2\n2\n2\n' == '1\n1\n1\n1\n...n2\n2\n2\n2\n'
>> E ? ? ? ? Skipping 1990 identical leading characters in diff
>> E ? ? ? ? Skipping 1991 identical trailing characters in diff
>> E ? ? ? ? ? 1
>> E ? ? ? ? ? 1
>> E ? ? ? ? ? 1
>> E ? ? ? ? ? 1
>> E ? ? ? ? ? 1
>> E ? ? ? ? - abc2
>> E ? ? ? ? + def2
>> E ? ? ? ? ? 2
>> E ? ? ? ? ? 2
>> E ? ? ? ? ? 2
>> E ? ? ? ? ? 2
>
>
> looks good to me!

I've committed a cleaned-up version of this now.


>> This whole issue made me wonder if it should be possible to disable
>> the pytest_assert_binrepr hook.
>
> We could do a general "--assertmode=(choice)" with e.g.:
>
> ? ?0: (no) don't do any assert reinterp (like --no-assert now)
> ? ?1: (basic) do basic reinterpreation
> ? ?2: (advanced) do basic reinterpretation + customizing hooks
>
> and default to 2.

Sounds like a good idea.  Do you think there's place for a
advanced-no-builtin-plugin option in here, so that the builtin hook
will not run any code?  Otherwise a bug in the builtin customisation
hook would completely stop this from being useful.


> I think there is an elegant solution. ?Instead of using "hook" in py/code/ we
> use a generic "customize" function that is to be called. ?In
> pytest_assertion.py's pytest_configure we write that function
> such that it calls
>
> ? ?pytest_assert_binrepr(config, ...)
>
> hope that makes sense. If in doubt leave it to me and just use py.test.config.

Do you mean something like the attached diff does?  In that case I'm
sort of tempted to remove the customise_assert() function I've added
there and just expose the DebugInterpreter so that you can modify the
attribute directly.  I also considered the
customise_assert(binrepr_hook, config) signature for this, not sure
which would be best.


Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.diff
Type: text/x-patch
Size: 3108 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20101001/75ab3c7b/attachment.bin 

From holger at merlinux.eu  Sat Oct  2 19:33:43 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 2 Oct 2010 19:33:43 +0200
Subject: [py-dev] controlling assertions and difflib
In-Reply-To: <AANLkTinY-2_d5+RqhEJ0dGXmY=PFJHwc_opQi=P-2OL5@mail.gmail.com>
References: <AANLkTimf7aY-BczSSVvfKFcNvD5BTz6bpE67OEsWyXjM@mail.gmail.com>
	<20100929132818.GK20695@trillke.net>
	<AANLkTinY-2_d5+RqhEJ0dGXmY=PFJHwc_opQi=P-2OL5@mail.gmail.com>
Message-ID: <20101002173342.GT20695@trillke.net>

Hey Floris,

On Fri, Oct 01, 2010 at 00:23 +0100, Floris Bruynooghe wrote:
> On 29 September 2010 14:28, holger krekel <holger at merlinux.eu> wrote:
> > On Wed, Sep 29, 2010 at 00:12 +0100, Floris Bruynooghe wrote:
> >> ______________________________ test_hang_in_diff _______________________________
> >> /tmp/sandbox/test_bugs.py:4: in test_hang_in_diff
> >> > ? ? ? assert x == y
> >> E ? ? ? assert '1\n1\n1\n1\n...n2\n2\n2\n2\n' == '1\n1\n1\n1\n...n2\n2\n2\n2\n'
> >> E ? ? ? ? Skipping 1990 identical leading characters in diff
> >> E ? ? ? ? Skipping 1991 identical trailing characters in diff
> >> E ? ? ? ? ? 1
> >> E ? ? ? ? ? 1
> >> E ? ? ? ? ? 1
> >> E ? ? ? ? ? 1
> >> E ? ? ? ? ? 1
> >> E ? ? ? ? - abc2
> >> E ? ? ? ? + def2
> >> E ? ? ? ? ? 2
> >> E ? ? ? ? ? 2
> >> E ? ? ? ? ? 2
> >> E ? ? ? ? ? 2
> >
> >
> > looks good to me!
> 
> I've committed a cleaned-up version of this now.

Great, thanks.  It's now merged to py-trunk!
 
> >> This whole issue made me wonder if it should be possible to disable
> >> the pytest_assert_binrepr hook.
> >
> > We could do a general "--assertmode=(choice)" with e.g.:
> >
> > ? ?0: (no) don't do any assert reinterp (like --no-assert now)
> > ? ?1: (basic) do basic reinterpreation
> > ? ?2: (advanced) do basic reinterpretation + customizing hooks
> >
> > and default to 2.
> 
> Sounds like a good idea.  Do you think there's place for a
> advanced-no-builtin-plugin option in here, so that the builtin hook
> will not run any code?  Otherwise a bug in the builtin customisation
> hook would completely stop this from being useful.

I am not so afraid but we can do it.  
 
> > I think there is an elegant solution. ?Instead of using "hook" in py/code/ we
> > use a generic "customize" function that is to be called. ?In
> > pytest_assertion.py's pytest_configure we write that function
> > such that it calls
> >
> > ? ?pytest_assert_binrepr(config, ...)
> >
> > hope that makes sense. If in doubt leave it to me and just use py.test.config.
> 
> Do you mean something like the attached diff does?  In that case I'm
> sort of tempted to remove the customise_assert() function I've added
> there and just expose the DebugInterpreter so that you can modify the
> attribute directly.  I also considered the
> customise_assert(binrepr_hook, config) signature for this, not sure
> which would be best.

I think i meant something different.  Please have a look into this 
changeset which i just added:

    http://bitbucket.org/hpk42/py-trunk/changeset/64962794201b

does this make sense to you? 

Also did a subsequent commit to rename to pytest_assertrepr_compare which
now can get a config object so we can now introduce variations controled 
by config values. 

best,
holger

> 
> 
> Regards
> Floris
> 
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org

> diff --git a/py/__init__.py b/py/__init__.py
> --- a/py/__init__.py
> +++ b/py/__init__.py
> @@ -99,6 +99,7 @@ py.apipkg.initpkg(__name__, dict(
>          '_AssertionError'   : '._code.assertion:AssertionError',
>          '_reinterpret_old'  : '._code.assertion:reinterpret_old',
>          '_reinterpret'      : '._code.assertion:reinterpret',
> +        'customise_assert'  : '._code._assertionnew:customise_assert',
>      },
>  
>      # backports and additions of builtins
> diff --git a/py/_code/_assertionnew.py b/py/_code/_assertionnew.py
> --- a/py/_code/_assertionnew.py
> +++ b/py/_code/_assertionnew.py
> @@ -107,17 +107,21 @@ unary_map = {
>  }
>  
>  
> +def customise_assert(config):
> +    """Customise the DebugInterpreter with pytest config"""
> +    DebugInterpreter.pytest_config = config
> +
> +
>  class DebugInterpreter(ast.NodeVisitor):
>      """Interpret AST nodes to gleam useful debugging information.
>  
>      The _pytesthook attribute is used to detect if the py.test
>      pytest_assertion plugin is loaded and if so call it's hooks.
>      """
> +    pytest_config = None
>  
>      def __init__(self, frame):
>          self.frame = frame
> -        self._pytesthook = getattr(py.builtin.builtins.AssertionError,
> -                                   "_pytesthook")
>  
>      def generic_visit(self, node):
>          # Fallback when we don't have a special implementation.
> @@ -183,9 +191,10 @@ class DebugInterpreter(ast.NodeVisitor):
>              if not result:
>                  break
>              left_explanation, left_result = next_explanation, next_result
> -        if self._pytesthook:
> -            hook_result = self._pytesthook.pytest_assert_binrepr(
> -                op=op_symbol, left=left_result, right=next_result)
> +        if self.pytest_config:
> +            hook_result = self.pytest_config.hook.pytest_assert_binrepr(
> +                op=op_symbol, left=left_result, right=next_result,
> +                config=self.pytest_config)
>              if hook_result:
>                  for new_expl in hook_result:
>                      if new_expl:
> diff --git a/py/_plugin/hookspec.py b/py/_plugin/hookspec.py
> --- a/py/_plugin/hookspec.py
> +++ b/py/_plugin/hookspec.py
> @@ -127,7 +127,7 @@ def pytest_sessionfinish(session, exitst
>  # hooks for customising the assert methods
>  # -------------------------------------------------------------------------
>  
> -def pytest_assert_binrepr(op, left, right):
> +def pytest_assert_binrepr(op, left, right, config):
>      """Customise explanation for binary operators
>  
>      Return None or an empty list for no custom explanation, otherwise
> diff --git a/py/_plugin/pytest_assertion.py b/py/_plugin/pytest_assertion.py
> --- a/py/_plugin/pytest_assertion.py
> +++ b/py/_plugin/pytest_assertion.py
> @@ -16,7 +16,7 @@ def pytest_configure(config):
>          warn_about_missing_assertion()
>          config._oldassertion = py.builtin.builtins.AssertionError
>          py.builtin.builtins.AssertionError = py.code._AssertionError
> -        py.builtin.builtins.AssertionError._pytesthook = config.hook
> +        py.code.customise_assert(config)
>  
>  def pytest_unconfigure(config):
>      if hasattr(config, '_oldassertion'):

> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev


-- 

From issues-noreply at bitbucket.org  Sun Oct  3 15:56:09 2010
From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org)
Date: Sun, 03 Oct 2010 13:56:09 -0000
Subject: [py-dev] New issue 125 in py-trunk: py.test exits when TypeError
	raises in __init__
Message-ID: <0293e80b053607d381ec2e6f140f597d@bitbucket.org>

--- you can reply above this line ---

New issue 125: py.test exits when TypeError raises in __init__
http://bitbucket.org/hpk42/py-trunk/issue/125/pytest-exits-when-typeerror-raises-in

Alfredo Deza / alfredodeza on Sun, 3 Oct 2010 15:56:09 +0200:

Description:
  When testing a class that raises TypeError (the test assumed the __init__ had an attribute that didn't exist) py.test exits without a traceback.

Even when running py.test in verbose mode or with --fulltrace it still doesn't report why the test is failing.

Running the test with python (e.g. no test suite) the traceback is reported correctly.

This is how it looks with py.test:
{{{
#!bash

py.test --fulltrace -v test_hg.py
================ test session starts ==============
platform darwin -- Python 2.6.1 -- pytest-1.3.4 -- /Users/alfredo/python/vpacha/bin/python
test path 1: test_hg.py

test_hg.py:43: TestHg.test_clone FAIL
test_hg.py:64: TestHg.test_commit %   
}}}
 
This is how running it with Python looks:

{{{
python test_hg.py                
EEEEEEEEEE
===========================
ERROR: Builds a mercurial repo and commits
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_hg.py", line 71, in test_commit
    conf=self.dict_conf)
TypeError: __init__() got an unexpected keyword argument 'conf'


}}}

I'm truncating the rest of tests that fail running with Python and showing the full output with 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 flub at devork.be  Tue Oct  5 21:16:27 2010
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 5 Oct 2010 20:16:27 +0100
Subject: [py-dev] controlling assertions and difflib
In-Reply-To: <20101002173342.GT20695@trillke.net>
References: <AANLkTimf7aY-BczSSVvfKFcNvD5BTz6bpE67OEsWyXjM@mail.gmail.com>
	<20100929132818.GK20695@trillke.net>
	<AANLkTinY-2_d5+RqhEJ0dGXmY=PFJHwc_opQi=P-2OL5@mail.gmail.com>
	<20101002173342.GT20695@trillke.net>
Message-ID: <AANLkTik4=_UTaFo+pdQ-yBe3Bf0DYeuwqNnf+99P3i-u@mail.gmail.com>

Hello Holger

On 2 October 2010 18:33, holger krekel <holger at merlinux.eu> wrote:
> On Fri, Oct 01, 2010 at 00:23 +0100, Floris Bruynooghe wrote:
>> I've committed a cleaned-up version of this now.
>
> Great, thanks. ?It's now merged to py-trunk!

Great!

>> >> This whole issue made me wonder if it should be possible to disable
>> >> the pytest_assert_binrepr hook.
>> >
>> > We could do a general "--assertmode=(choice)" with e.g.:
>> >
>> > ? ?0: (no) don't do any assert reinterp (like --no-assert now)
>> > ? ?1: (basic) do basic reinterpreation
>> > ? ?2: (advanced) do basic reinterpretation + customizing hooks
>> >
>> > and default to 2.
>>
>> Sounds like a good idea. ?Do you think there's place for a
>> advanced-no-builtin-plugin option in here, so that the builtin hook
>> will not run any code? ?Otherwise a bug in the builtin customisation
>> hook would completely stop this from being useful.
>
> I am not so afraid but we can do it.

Ok, never mind.


> I think i meant something different. ?Please have a look into this
> changeset which i just added:
>
> ? ?http://bitbucket.org/hpk42/py-trunk/changeset/64962794201b
>
> does this make sense to you?

Yes, that makes more sense.  Very neat.


Is there still anything you'd like me to do on this?  E.g. adding the
--assertmode (and leave --no-assert as an alias for --assertmode=0).
Personally I'm pretty neutral on that in retrospect.


Thanks for merging this.
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From flub at devork.be  Tue Oct  5 22:22:40 2010
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 5 Oct 2010 21:22:40 +0100
Subject: [py-dev] Assert repr of attributes
Message-ID: <AANLkTikvkoQesxi1CCxCYbRFY9M25fwCAHdDLzYkCLWG@mail.gmail.com>

Hello

Another possible improvement to the assert repr of py.test (IMHO) is
how attributes are represented.  One thing I often find myself doing
is code like this:

def test_foo():
    i = SomeClass()
    print i.attribute_name
    assert i.attribute_name == "some_value"

The printing of the attribute name is simply to work around the
slightly annoying (IMHO) default representation of attributes, it
could have been a one-liner test otherwise (assuming no side-effects
in the call).  While it is really nice to see where it came from, just
knowing the value is often very useful (e.g. when it could be None or
a meaning value).

So the attached patch addresses this.  It's just a one-line change
really, and I think the output is a lot nicer.  Personally I can't see
what could be wrong with this approach so don't think moving this to a
plugin or making it otherwise optional is needed.

I hope this can be a useful addition.

Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attrib.diff
Type: text/x-patch
Size: 2535 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20101005/b6b012ae/attachment.bin 

From issues-noreply at bitbucket.org  Wed Oct  6 10:37:27 2010
From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org)
Date: Wed, 06 Oct 2010 08:37:27 -0000
Subject: [py-dev] New issue 126 in py-trunk: Automatically disable capturing
 when pdb.set_trace() is called
Message-ID: <ab98cb353c5f54954afac06e4e3ebb45@bitbucket.org>

--- you can reply above this line ---

New issue 126: Automatically disable capturing when pdb.set_trace() is called
http://bitbucket.org/hpk42/py-trunk/issue/126/automatically-disable-capturing-when-pdbset_trace-is

Antonio Cuni / antocuni on Wed, 6 Oct 2010 10:37:27 +0200:

Description:
  Currently, if I have a pdb.set_trace() call in my code and run py.test without -s, I get an IOError instead of the pdb prompt.

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  Wed Oct  6 10:55:41 2010
From: holger at merlinux.eu (holger krekel)
Date: Wed, 6 Oct 2010 10:55:41 +0200
Subject: [py-dev] Assert repr of attributes
In-Reply-To: <AANLkTikvkoQesxi1CCxCYbRFY9M25fwCAHdDLzYkCLWG@mail.gmail.com>
References: <AANLkTikvkoQesxi1CCxCYbRFY9M25fwCAHdDLzYkCLWG@mail.gmail.com>
Message-ID: <20101006085540.GY20695@trillke.net>

Hi Floris,

On Tue, Oct 05, 2010 at 21:22 +0100, Floris Bruynooghe wrote:
> Hello
> 
> Another possible improvement to the assert repr of py.test (IMHO) is
> how attributes are represented.  One thing I often find myself doing
> is code like this:
> 
> def test_foo():
>     i = SomeClass()
>     print i.attribute_name
>     assert i.attribute_name == "some_value"

Yes, this annoyed me as well a couple of times :) 
 
> The printing of the attribute name is simply to work around the
> slightly annoying (IMHO) default representation of attributes, it
> could have been a one-liner test otherwise (assuming no side-effects
> in the call).  While it is really nice to see where it came from, just
> knowing the value is often very useful (e.g. when it could be None or
> a meaning value).
> 
> So the attached patch addresses this.  It's just a one-line change
> really, and I think the output is a lot nicer.  Personally I can't see
> what could be wrong with this approach so don't think moving this to a
> plugin or making it otherwise optional is needed.

right.  There was something that was problematic IIRC but i am not sure
what it was.  And it surely is useful.  So let's apply it :) 

Can you create a bundle for this changeset 
or let me pull this change from your repo? 

> I hope this can be a useful addition.

sure!
holger

From issues-noreply at bitbucket.org  Wed Oct  6 15:25:44 2010
From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org)
Date: Wed, 06 Oct 2010 13:25:44 -0000
Subject: [py-dev] New issue 127 in py-trunk: py.test doesn't wait for
 deferred completion when using twisted.trial
Message-ID: <b26fb0f13cb60078e54766cbdd9415d6@bitbucket.org>

--- you can reply above this line ---

New issue 127: py.test doesn't wait for deferred completion when using twisted.trial
http://bitbucket.org/hpk42/py-trunk/issue/127/pytest-doesnt-wait-for-deferred-completion-when-using

Ali Afshar / aafshar on Wed, 6 Oct 2010 15:25:44 +0200:

Description:
  Twisted.trial unittests have an additional feature where if they return a deferred, the deferred will be waited on until completed. This behaviour is present in the base TestCase class twisted.trial.unittest.TestCase. These deferreds are not currently waited on in py.test.


Additionally, some twisted unittests are presented as generators decorated by  twisted.internet.defer.inlineCallbacks in which yield yields a deferreds. These generators should be iterated to completion and all generators waited upon for completion.


This is just a placeholder, as I should investigate this myself, and add more information to this ticket.

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 flub at devork.be  Wed Oct  6 19:25:00 2010
From: flub at devork.be (Floris Bruynooghe)
Date: Wed, 6 Oct 2010 18:25:00 +0100
Subject: [py-dev] Assert repr of attributes
In-Reply-To: <20101006085540.GY20695@trillke.net>
References: <AANLkTikvkoQesxi1CCxCYbRFY9M25fwCAHdDLzYkCLWG@mail.gmail.com>
	<20101006085540.GY20695@trillke.net>
Message-ID: <AANLkTinfFijffKnodX3XKd5py4dxrLNG9eAeXiDTKJ8E@mail.gmail.com>

On 6 October 2010 09:55, holger krekel <holger at merlinux.eu> wrote:

> Can you create a bundle for this changeset
> or let me pull this change from your repo?

Bundle attached (which produces slightly better output then the original patch).

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attrib.hg
Type: application/octet-stream
Size: 1420 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20101006/e7071b96/attachment.obj 

From issues-noreply at bitbucket.org  Thu Oct  7 14:48:00 2010
From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org)
Date: Thu, 07 Oct 2010 12:48:00 -0000
Subject: [py-dev] New issue 128 in py-trunk: py.test does not show
 SyntaxErrors when using --pdb
Message-ID: <73fff333b0014f8a5b78ac10676f96e1@bitbucket.org>

--- you can reply above this line ---

New issue 128: py.test does not show SyntaxErrors when using --pdb
http://bitbucket.org/hpk42/py-trunk/issue/128/pytest-does-not-show-syntaxerrors-when-using

Antonio Cuni / antocuni on Thu, 7 Oct 2010 14:48:00 +0200:

Description:
  If the test file contains a SyntaxError, py.test --pdb silently fails without telling anything about the cause:

{{{
$ cat test_syntax_error.py 
a =
$ py.test test_syntax_error.py 
================================= test session starts ==================================
platform linux2 -- Python 2.6.5 -- pytest-1.4.0a1

/tmp/foo/test_syntax_error.py E
test path 1: test_syntax_error.py

======================================== ERRORS ========================================
____________________ ERROR collecting /tmp/foo/test_syntax_error.py ____________________
/home/antocuni/pypy/misc/py-trunk/py/_plugin/pytest_python.py:216: in _importtestmodule
>           mod = self.fspath.pyimport(ensuresyspath=True)
/home/antocuni/pypy/misc/py-trunk/py/_path/local.py:530: in pyimport
>           mod = __import__(modname, None, None, ['__doc__'])
E             File "/tmp/foo/test_syntax_error.py", line 1
E               a =
E                 ^
E           SyntaxError: invalid syntax
=============================== 1 error in 0.02 seconds ================================
$ py.test test_syntax_error.py --pdb
================================= test session starts ==================================
platform linux2 -- Python 2.6.5 -- pytest-1.4.0a1

/tmp/foo/test_syntax_error.py E
test path 1: test_syntax_error.py

=============================== 1 error in 0.04 seconds ================================
$ 
}}}




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  Sun Oct 10 15:03:44 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 10 Oct 2010 15:03:44 +0200
Subject: [py-dev] the split is happening: py -> pytest,pylib,pycmd
Message-ID: <20101010130343.GC11924@trillke.net>

Hi all,

if you happen to pull/update from the bitbucket "py-trunk" repo
you'll find it contains almost no files anymore but rather has a setup.py
that specifies dependencies on the following split out distributions:

    * pytest: https://bitbucket.org/hpk42/pytest

    * pylib: https://bitbucket.org/hpk42/pylib

    * pycmd: https://bitbucket.org/hpk42/pycmd

Nothing is released to PYPI yet and there are certainly some rough edges.

However, you should be able to grab the above repos and issue
"python setup.py develop" in each (first on pylib, then pytest).

I am currently working a lot on documentation and further 
refinements to packaging.   Feedback/comments welcome.

best,
holger

From anto.cuni at gmail.com  Sun Oct 10 15:12:17 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sun, 10 Oct 2010 15:12:17 +0200
Subject: [py-dev] the split is happening: py -> pytest,pylib,pycmd
In-Reply-To: <20101010130343.GC11924@trillke.net>
References: <20101010130343.GC11924@trillke.net>
Message-ID: <4CB1BBB1.3090301@gmail.com>

Hi!

On 10/10/10 15:03, holger krekel wrote:
> Hi all,
>
> if you happen to pull/update from the bitbucket "py-trunk" repo
> you'll find it contains almost no files anymore but rather has a setup.py
> that specifies dependencies on the following split out distributions:
>
>      * pytest: https://bitbucket.org/hpk42/pytest
>
>      * pylib: https://bitbucket.org/hpk42/pylib
>
>      * pycmd: https://bitbucket.org/hpk42/pycmd

I've quickly looked at the repos, but there is something that I don't get: I 
see that there is still pycmd/pycmd/pytest.py, however pytest is not listed in 
the dependencies.

Does it simply mean that you forgot to remove pytest.py from pycmd, or that 
pycmd will be required to get the py.test executable?

ciao,
Anto

From holger at merlinux.eu  Sun Oct 10 15:17:01 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 10 Oct 2010 15:17:01 +0200
Subject: [py-dev] the split is happening: py -> pytest,pylib,pycmd
In-Reply-To: <4CB1BBB1.3090301@gmail.com>
References: <20101010130343.GC11924@trillke.net> <4CB1BBB1.3090301@gmail.com>
Message-ID: <20101010131701.GD11924@trillke.net>

On Sun, Oct 10, 2010 at 15:12 +0200, Antonio Cuni wrote:
> On 10/10/10 15:03, holger krekel wrote:
>> Hi all,
>>
>> if you happen to pull/update from the bitbucket "py-trunk" repo
>> you'll find it contains almost no files anymore but rather has a setup.py
>> that specifies dependencies on the following split out distributions:
>>
>>      * pytest: https://bitbucket.org/hpk42/pytest
>>
>>      * pylib: https://bitbucket.org/hpk42/pylib
>>
>>      * pycmd: https://bitbucket.org/hpk42/pycmd
>
> I've quickly looked at the repos, but there is something that I don't 
> get: I see that there is still pycmd/pycmd/pytest.py, however pytest is 
> not listed in the dependencies.

thanks, removed.

> Does it simply mean that you forgot to remove pytest.py from pycmd, or 
> that pycmd will be required to get the py.test executable?

i forgot it. there may be other places like this. Thanks for looking.
best,
holger

From issues-noreply at bitbucket.org  Tue Oct 12 17:32:46 2010
From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org)
Date: Tue, 12 Oct 2010 15:32:46 -0000
Subject: [py-dev] New issue 129 in py-trunk: Test file names of the form
 foo_bar___init__.py error in 1.3.2, 1.3.3 and 1.3.4
Message-ID: <c02f3ad338bb4aac48aa4253f934ea38@bitbucket.org>

--- you can reply above this line ---

New issue 129: Test file names of the form foo_bar___init__.py error in 1.3.2, 1.3.3 and 1.3.4
http://bitbucket.org/hpk42/py-trunk/issue/129/test-file-names-of-the-form-foo_bar___init__py-error-in-132-133-and

trevorbaca on Tue, 12 Oct 2010 17:32:46 +0200:

Description:
  Hi,

Starting in 1.3.2 test file names *ending with* the string '__init__.py' cause py.test to fail.

This would seem to relate to #119 (fixed in 1.3.4). But this version of the problem persists in the 1.3.4 public release.

In the example below, the file foo_bar___init__.py contains just a single print statement:


Desktop$ py.test foo_bar__init__.py 
======================================= test session starts ========================================
platform darwin -- Python 2.6.1 -- pytest-1.3.4
test path 1: foo_bar__init__.py

foo_bar__init__.py E

============================================== ERRORS ==============================================
__________________ ERROR collecting /Users/trevorbaca/Desktop/foo_bar__init__.py ___________________
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_plugin/pytest_runner.py:34: in pytest_make_collect_report
>           result = collector._memocollect()
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_test/collect.py:230: in _memocollect
>       return self._memoizedcall('_collected', self.collect)
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_test/collect.py:104: in _memoizedcall
>           res = function()
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_test/pycollect.py:82: in collect
>       dicts = [getattr(self.obj, '__dict__', {})]
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_test/pycollect.py:17: in fget
>           self._obj = obj = self._getobj()
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_test/pycollect.py:140: in _getobj
>       return self._memoizedcall('_obj', self._importtestmodule)
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_test/collect.py:104: in _memoizedcall
>           res = function()
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_test/pycollect.py:145: in _importtestmodule
>           mod = self.fspath.pyimport(ensuresyspath=True)
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_path/local.py:539: in pyimport
>           if not self.samefile(modfile):
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_path/local.py:73: in samefile
>       return py.error.checked_call(os.path.samefile, str(self), str(other))
/Library/Python/2.6/site-packages/py-1.3.4-py2.6.egg/py/_error.py:80: in checked_call
>           raise cls("%s%r" % (func.__name__, args))
E           ENOENT: [No such file or directory]: samefile('/Users/trevorbaca/Desktop/foo_bar__init__.py', '/Users/trevorbaca/Desktop/foo_ba')
===================================== 1 error in 0.09 seconds ======================================


This matters for us at www.projectabjad.org because we author tests for the initializers of all of our classes in files named as FooBarClass___init__.py.

Trevor.

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 fijall at gmail.com  Tue Oct 12 18:31:09 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 12 Oct 2010 18:31:09 +0200
Subject: [py-dev] do you mind the issue-postings here?
In-Reply-To: <20100903153034.GE32478@trillke.net>
References: <20100903153034.GE32478@trillke.net>
Message-ID: <AANLkTinGNMMLZPPvg_8E6oy6O81ysGTDnvj3-Ben+zr4@mail.gmail.com>

personally, I think a separate mailing list would be better (I've
started to ignore py-dev and I think issues played major part), but I
can only speak about myself.

On Fri, Sep 3, 2010 at 5:30 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi all,
>
> am wondering: do you mind seeing new bitbucket issue
> creations here on the mailing list? ?If so i'll create
> a new mailing list pypy-issue or so and have things
> rather sent there. Just let me know.
>
> Personally i find it a bit unfortuante that the many
> closed/resolved issues are not notified to this list as well :)
>
> cheers,
> holger
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
>

From holger at merlinux.eu  Fri Oct 15 01:13:15 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 15 Oct 2010 01:13:15 +0200
Subject: [py-dev] installing new py.test / new pypi.testrun.org
Message-ID: <20101014231315.GR11924@trillke.net>

Hi, 

i created a simple PyPI server instance as a playground and to make 
it easier to test interdependent packagages i am working on.  See

    http://pypi.testrun.org

You can use it to install the latest in-development version of pytest,
tox, pylib, pycmd, pytest-xdist etc. (*) with e. g.:

    pip install -i http://pypi.testrun.org pytest 

or tox::

    pip install -i http://pypi.testrun.org tox

These are _development_ versions so they might break more easily.
But they also fix a number of bugs and provide some new features :)

cheers,
holger


From holger at merlinux.eu  Fri Oct 15 20:14:26 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 15 Oct 2010 20:14:26 +0200
Subject: [py-dev] pytest / pylib / tox release splitting plan
Message-ID: <20101015181425.GZ11924@trillke.net>

Hi all,

here are some py.test/pylib/tox split release related stories i have been
thinking about.  Idea is to allow all kinds of installation / upgrade situations
to succeed.  My goal is to have "tox" only pull in the new small and mean
"pylib" and not the whole pytest package. Another is to have a small mostly
self-contained "pytest" package. And a third to seperate out the helper
tools into a "pycmd" package.  

Anyone who is interested in release management might want to read this,
and maybe help me see the light or be inspired ... all others can just 
hope i get this right and don't mess up :) 

consider this situation:

    pip install py     # you currently get sumo py==1.3.4, for using py.test
    pip install pylib  # will be pylib==2.0.0

this would lead to "import py" coming from py==1.3.4 because the distribution
'py' "owns py" and came first.  You'd also see funny tracebacks when invoking
py.test. BAD.

My planned fix is to provide a py==1.4.0 which has _no_ packages
and have pylib depend on the exact "py==1.4.0" version.  Then

    pip install pylib  

will lead to "import py" coming from pylib-2.0.0 because the py==1.4.0 
is an upgrade to 1.3.4, thus removes its "py", package, no interference.  Good.

Now consider a tox user, typing::

    pip install tox   # let's assume this is 0.8

tox has a requirement of "py" and if this drags py==1.4.0 - BUMM!
the tox installs breaks, because when it "import py" nothing is there.

My planned fix is to provide *another* release "py==1.4.1" which will depend on
pylib-2.0 and pytest-2.0 (and pycmd-1.0) so that people blindly installing  tox
like above will be happy and people doing 

    pip install -U py

and expecting to get py.test (because they are reading an old README
or blog post) will also be happy and use the newest version of pytest/pylib.

Finally, somebody starting a fresh installation with

    pip install pytest 

will just drag in pylib-2.0, which drags in py==1.4.0 which requires
pylib-2.0 ... SIMPLE, good.

You might wonder why i care so much and don't simply tell people
"make sure you uninstall py first" or something like this.

Reason: many people are using the above packages in Continous
Integration situations and going to all kinds of masters, slaves
and Job configurations to ensure removal of packages and such
is not fun.  And not everybody reads release messages anyway ...
or understands what is installed in their environments - judging
from myself :) 

best,
holger

From anto.cuni at gmail.com  Sat Oct 16 19:05:29 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sat, 16 Oct 2010 19:05:29 +0200
Subject: [py-dev] Detect whether py.test is running
Message-ID: <4CB9DB59.50501@gmail.com>

Hi,

I need a way to distinguish whether the current module is being imported 
because we are running the tests, of whether we are running the main program.

I know that the correct way would be to inject the information from the top, 
but I'm using a framework which relies on some global state to store the 
various options, and I have to deal with it.

Anyway, is there any official/recommended way to do it?
What I'm doing right now is this (py 1.3.1):

if py.test.config.__dict__ == {}:
     # py.test is NOT running
     ...
else:
     # py.test is running

ciao,
Anto

From anto.cuni at gmail.com  Sat Oct 16 19:09:18 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sat, 16 Oct 2010 19:09:18 +0200
Subject: [py-dev] Detect whether py.test is running
In-Reply-To: <4CB9DB59.50501@gmail.com>
References: <4CB9DB59.50501@gmail.com>
Message-ID: <4CB9DC3E.9040901@gmail.com>

On 16/10/10 19:05, Antonio Cuni wrote:

> if py.test.config.__dict__ == {}:

sorry, it's py.test.config.option.__dict__

(uhm, what about providing a way to test the code inside the emails before 
sending them? :-))

From holger at merlinux.eu  Sat Oct 16 22:56:43 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 16 Oct 2010 22:56:43 +0200
Subject: [py-dev] Detect whether py.test is running
In-Reply-To: <4CB9DB59.50501@gmail.com>
References: <4CB9DB59.50501@gmail.com>
Message-ID: <20101016205643.GC11924@trillke.net>

Hi Anto, all,

First of all, please keep asking "usage" questions or ask for examples
for practical / real life problems you have.  They help me filling
the example sections of the new py.test docs with useful material :)

On Sat, Oct 16, 2010 at 19:05 +0200, Antonio Cuni wrote:
> I need a way to distinguish whether the current module is being imported 
> because we are running the tests, of whether we are running the main program.
> 
> I know that the correct way would be to inject the information from the top, 
> but I'm using a framework which relies on some global state to store the 
> various options, and I have to deal with it.

Right, which is why i wouldn't like this to be totally convenient :)

> Anyway, is there any official/recommended way to do it?
> What I'm doing right now is this (py 1.3.1):
> 
> if py.test.config.__dict__ == {}:
>      # py.test is NOT running
>      ...
> else:
>      # py.test is running

uh, hacky :)  also will break with pytest-2.0 as the py.test.config
will not be there outside of test runs.

I drafted an example which should also work with py-1.3.1 as part of
the examples section of the upcoming pytest docs:

    http://codespeak.net/~hpk/pytest/example/misc.html

Works for you?

cheers,
holger

From red_socks at gmx.de  Sun Oct 17 10:59:45 2010
From: red_socks at gmx.de (Frank Hempel)
Date: Sun, 17 Oct 2010 10:59:45 +0200
Subject: [py-dev] Detect whether py.test is running
In-Reply-To: <20101016205643.GC11924@trillke.net>
References: <4CB9DB59.50501@gmail.com> <20101016205643.GC11924@trillke.net>
Message-ID: <4CBABB01.3050304@gmx.de>

Am 16.10.2010 22:56, schrieb holger krekel:
...
> I drafted an example which should also work with py-1.3.1 as part of
> the examples section of the upcoming pytest docs:
> 
>     http://codespeak.net/~hpk/pytest/example/misc.html

I guess it's a typo:

"Usually it is a good idea to make application code behave differently
if called from a test."

It's usually a bad idea, isn't it?

Regards, Frank

From holger at merlinux.eu  Sun Oct 17 11:11:16 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 17 Oct 2010 11:11:16 +0200
Subject: [py-dev] Detect whether py.test is running
In-Reply-To: <4CBABB01.3050304@gmx.de>
References: <4CB9DB59.50501@gmail.com> <20101016205643.GC11924@trillke.net>
	<4CBABB01.3050304@gmx.de>
Message-ID: <20101017091116.GD11924@trillke.net>

On Sun, Oct 17, 2010 at 10:59 +0200, Frank Hempel wrote:
> Am 16.10.2010 22:56, schrieb holger krekel:
> ...
> > I drafted an example which should also work with py-1.3.1 as part of
> > the examples section of the upcoming pytest docs:
> > 
> >     http://codespeak.net/~hpk/pytest/example/misc.html
> 
> I guess it's a typo:
> 
> "Usually it is a good idea to make application code behave differently
> if called from a test."
> 
> It's usually a bad idea, isn't it?

right. fixed. thanks!
holger

From anto.cuni at gmail.com  Sun Oct 17 22:24:46 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sun, 17 Oct 2010 22:24:46 +0200
Subject: [py-dev] Detect whether py.test is running
In-Reply-To: <20101016205643.GC11924@trillke.net>
References: <4CB9DB59.50501@gmail.com> <20101016205643.GC11924@trillke.net>
Message-ID: <4CBB5B8E.3000909@gmail.com>

Hi Holger, hi all

On 16/10/10 22:56, holger krekel wrote:
> Hi Anto, all,
>
> First of all, please keep asking "usage" questions or ask for examples
> for practical / real life problems you have.  They help me filling
> the example sections of the new py.test docs with useful material :)

sorry, I don't get it. Do you mean that I should describe my problem in more 
details? Ok, here is it.

I am developing a program using scrapy (to get data from web pages). Following 
the (bad?) habit of lot of frameworks, scrapy requires you to define some 
settings as global variables in a settings.py module.  In particular, the 
LOG_FILE variable determine where the log is written.

In my program, I would like the log file to be placed in a directory named 
after the date, e.g. '2010-10-17/myprogram.log'.  So, my settings.py contains 
something like:

LOGDIR = BASEDIR.join(str(datetime.date.today()))
LOGDIR.ensure(dir=True)
LOG_FILE = LOGDIR.join('myprogram.log')

The issue is simply that I don't want to create the directory when I run the 
test, as the log file is not needed (and even if it were, I'd want it to be in 
a separate tmpdir, not in the main directory).

All the other solutions I could think of require to change the code in scrapy 
itself, which I'd prefer not to do, of course.


> Right, which is why i wouldn't like this to be totally convenient :)

+1 :-)


> uh, hacky :)  also will break with pytest-2.0 as the py.test.config
> will not be there outside of test runs.
>
> I drafted an example which should also work with py-1.3.1 as part of
> the examples section of the upcoming pytest docs:
>
>      http://codespeak.net/~hpk/pytest/example/misc.html
>
> Works for you?

I've not tried it yet, but should work and it's much better than my current 
approach :-). Thanks!

ciao,
Anto

From holger at merlinux.eu  Wed Oct 20 09:57:54 2010
From: holger at merlinux.eu (holger krekel)
Date: Wed, 20 Oct 2010 09:57:54 +0200
Subject: [py-dev] Detect whether py.test is running
In-Reply-To: <4CBB5B8E.3000909@gmail.com>
References: <4CB9DB59.50501@gmail.com> <20101016205643.GC11924@trillke.net>
	<4CBB5B8E.3000909@gmail.com>
Message-ID: <20101020075754.GE11924@trillke.net>

On Sun, Oct 17, 2010 at 22:24 +0200, Antonio Cuni wrote:
> Hi Holger, hi all
>
> On 16/10/10 22:56, holger krekel wrote:
>> Hi Anto, all,
>>
>> First of all, please keep asking "usage" questions or ask for examples
>> for practical / real life problems you have.  They help me filling
>> the example sections of the new py.test docs with useful material :)
>
> sorry, I don't get it. Do you mean that I should describe my problem in 
> more details? Ok, here is it.

Sorry for being unclear.  I just meant that i welcome your mail
and encourage everyone to ask similar questions.

> I am developing a program using scrapy (to get data from web pages). 
> Following the (bad?) habit of lot of frameworks, scrapy requires you to 
> define some settings as global variables in a settings.py module.  In 
> particular, the LOG_FILE variable determine where the log is written.
>
> In my program, I would like the log file to be placed in a directory 
> named after the date, e.g. '2010-10-17/myprogram.log'.  So, my 
> settings.py contains something like:
>
> LOGDIR = BASEDIR.join(str(datetime.date.today()))
> LOGDIR.ensure(dir=True)
> LOG_FILE = LOGDIR.join('myprogram.log')
>
> The issue is simply that I don't want to create the directory when I run 
> the test, as the log file is not needed (and even if it were, I'd want it 
> to be in a separate tmpdir, not in the main directory).
>
> All the other solutions I could think of require to change the code in 
> scrapy itself, which I'd prefer not to do, of course.
>
>
>> Right, which is why i wouldn't like this to be totally convenient :)
>
> +1 :-)
>
>
>> uh, hacky :)  also will break with pytest-2.0 as the py.test.config
>> will not be there outside of test runs.
>>
>> I drafted an example which should also work with py-1.3.1 as part of
>> the examples section of the upcoming pytest docs:
>>
>>      http://codespeak.net/~hpk/pytest/example/misc.html
>>
>> Works for you?
>
> I've not tried it yet, but should work and it's much better than my 
> current approach :-). Thanks!

good :)
cheers,
holger

From issues-noreply at bitbucket.org  Wed Oct 20 11:30:44 2010
From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org)
Date: Wed, 20 Oct 2010 09:30:44 -0000
Subject: [py-dev] New issue 130 in py-trunk: py.process.cmdexec fails if the
 out/err contains non-ascii characters
Message-ID: <58ef562c5a9bae1fe483285f47a4ed6e@bitbucket.org>

--- you can reply above this line ---

New issue 130: py.process.cmdexec fails if the out/err contains non-ascii characters
http://bitbucket.org/hpk42/py-trunk/issue/130/pyprocesscmdexec-fails-if-the-out-err-contains-non-ascii

Antonio Cuni / antocuni on Wed, 20 Oct 2010 11:30:44 +0200:

Description:
  Consider the following file trouble.py, which just output a non-ascii character to stdout:
{{{
# -*- encoding: utf-8 -*-
trouble = u'?'
print trouble.encode('utf-8')
}}}

py.process.cmdexec fails if we try to run it:
{{{
>>> import py
>>> py.process.cmdexec('python trouble.py')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antocuni/pypy/misc/py-trunk/py/_process/cmdexec.py", line 32, in cmdexec
    raise ExecutionFailed(status, status, cmd, out, err)
py.process.cmdexec.Error: ExecutionFailed: 1  python trouble.py
Traceback (most recent call last):
  File "trouble.py", line 3, in <module>
    print trouble
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe0' in position 0: ordinal not in range(128)
}}}

This happens because cmdexec try to decode stderr and stdout using sys.stdout.encoding or sys.getdefaultencoding(), which not necessarly match the output encoding of the program.

Real life use-case: a pypy test invokes gcc, which uses utf-8 characters for quotes. The test fails because of the exception inside cmdexec, even if the test itself completely ignores the stderr.

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 eli at water.ca.gov  Thu Oct 28 02:00:58 2010
From: eli at water.ca.gov (Ateljevich, Eli)
Date: Wed, 27 Oct 2010 17:00:58 -0700
Subject: [py-dev] py.test to control other testing framework
Message-ID: <67CC54752B3F8D43ACD7E3AD4551626306C423E88F@mrsbmapp20306.ad.water.ca.gov>

On another list, I asked Holger about how to use py.test as a wrapper to control non-python tests. He referred me to this example:
self-contained yaml example<http://codespeak.net/~hpk/pytest/example/nonpython.html>

This got me going on the issue of collecting and running the tests.

I have a follow-up question about aggregating results from these "foreign tests". I am using cxxunit, but the specifics are not important to my question. Each non-python test involves multiple asserts, failures and possibly errors. These test results could be reported in any of the usual formats (logs, stdout, JUnit xml format, custom).

My question is this: is there a good way to track assert pass/fail counts correctly in py.test?

One crude idea is to have cxxtest print out its assert attempts, passes and failures to a log, parse the log and then deliberately pass and fail a correct number of "shadow assertions" in python using the same log messages. Is there a more direct way?

Thanks,
Eli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20101027/9cff11d9/attachment.htm 

From prologic at shortcircuit.net.au  Thu Oct 28 02:17:21 2010
From: prologic at shortcircuit.net.au (James Mills)
Date: Thu, 28 Oct 2010 10:17:21 +1000
Subject: [py-dev] py.test with setuptools
Message-ID: <AANLkTi=oRMibmRCtuUojgBxTCbSARK+w44eMC-iaW7XB@mail.gmail.com>

Hey all,

Just curious... How do you setup your setup.py so that "python
setup.py tests" works ?

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

From holger at merlinux.eu  Thu Oct 28 08:52:35 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Oct 2010 08:52:35 +0200
Subject: [py-dev] py.test to control other testing framework
In-Reply-To: <67CC54752B3F8D43ACD7E3AD4551626306C423E88F@mrsbmapp20306.ad.water.ca.gov>
References: <67CC54752B3F8D43ACD7E3AD4551626306C423E88F@mrsbmapp20306.ad.water.ca.gov>
Message-ID: <20101028065234.GS11924@trillke.net>

Hi Eli,

On Wed, Oct 27, 2010 at 17:00 -0700, Ateljevich, Eli wrote:
> On another list, I asked Holger about how to use py.test as a wrapper to control non-python tests. He referred me to this example:
> self-contained yaml example<http://codespeak.net/~hpk/pytest/example/nonpython.html>
> 
> This got me going on the issue of collecting and running the tests.
> 
> I have a follow-up question about aggregating results from these "foreign tests". I am using cxxunit, but the specifics are not important to my question. Each non-python test involves multiple asserts, failures and possibly errors. These test results could be reported in any of the usual formats (logs, stdout, JUnit xml format, custom).

(sidenote: I guess you are aware of the --junitxml option.)

> My question is this: is there a good way to track assert pass/fail counts correctly in py.test?
> 
> One crude idea is to have cxxtest print out its assert attempts, passes and failures to a log, parse the log and then deliberately pass and fail a correct number of "shadow assertions" in python using the same log messages. Is there a more direct way?

Parsing a log sounds right.  However, there currently is no notion of "counting
asserts" in py.test (or other popular python testing frameworks i am aware of).

Do you happen to have a way to find out the number of test functions/cases
ahead of running a test file?  And to instruct cxxtest to run a particular
function?

If so you could map cxx test functions to py.test Items and get
more fine-granular "." printing and error representation.

Otherwise i guess you can only represent the whole cxxtest file as
one test item.  Also because of other scenarios i am wondering how/if
to help this situation, btw.  

cheers,
holger

From holger at merlinux.eu  Thu Oct 28 09:34:37 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Oct 2010 09:34:37 +0200
Subject: [py-dev] py.test with setuptools
In-Reply-To: <AANLkTi=oRMibmRCtuUojgBxTCbSARK+w44eMC-iaW7XB@mail.gmail.com>
References: <AANLkTi=oRMibmRCtuUojgBxTCbSARK+w44eMC-iaW7XB@mail.gmail.com>
Message-ID: <20101028073436.GT11924@trillke.net>

Hey James,

On Thu, Oct 28, 2010 at 10:17 +1000, James Mills wrote:
> Hey all,
> 
> Just curious... How do you setup your setup.py so that "python
> setup.py tests" works ?

I've written up an example of what i think is currently the best way 
to go about it for all distutils (or setuptools) based projects:

    http://codespeak.net/~hpk/pytest/goodpractises.html#integrating-with-distutils-python-setup-py-test

Another option probably is to hack a bit deeper into setuptools and/or 
to wrap a py.test run into unittest "suites".  The latter is maybe worth
to try out but the above documented method is very solid and avoids hassles
i think.

best,
holger
 
> cheers
> James
> 
> -- 
> -- James Mills
> --
> -- "Problems are solved by method"
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 

From holger at merlinux.eu  Fri Oct 29 00:00:54 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 29 Oct 2010 00:00:54 +0200
Subject: [py-dev] py.test to control other testing framework
In-Reply-To: <67CC54752B3F8D43ACD7E3AD4551626306C42E302C@mrsbmapp20306.ad.water.ca.gov>
References: <20101028065234.GS11924@trillke.net>
	<67CC54752B3F8D43ACD7E3AD4551626306C42E302C@mrsbmapp20306.ad.water.ca.gov>
Message-ID: <20101028220054.GV11924@trillke.net>

Hi Eli,

On Thu, Oct 28, 2010 at 14:11 -0700, Ateljevich, Eli wrote:
> Thanks Holger. I said wanted to count assertions but I was just being careless -- counting test failures and passes the usual way is fine. 
> 
> You seem to understand my timing issue by asking "do I know how many tests there are"?  I'll ask the cxxtest folks, but I haven't seen it in their usage examples and there is no obvious --count-tests type of flag. Python would see each cxxtest suite as a monolith.
> 
> One alternative is to lie to the py.test reporting mechanism. If I understand that code snippet you pointed out, I get a shot at this in repr_failure(self, excinfo). Is excinfo an opportunity to manipulate test attributes enough to increase the total, success and fail counts:
> 1. Collector discovers cxxtests
> 2. Runner runs them
> 3. Runner parses the success/fail results and stashes them
> 4. Runner lies in repr_failure(self,excinfo), upping the counts
> Even if this is possible, it seems like at most I can do this on failure -- the number of tests and successes would be hard to count correctly. 

You can't really "lie in repr_failure" regarding test counts.   We could maybe
think about allowing multiple reports per test item. Haven't tried this
and am a bit skeptical about it producing internal problems.  It might be
surprising for other plugins like the junitxml plugin or the terminal
plugin itself which assume they get one report per collected test item IIRC.
However, it's worth an experiment i guess especially since Ronny (another
py.test hacker and heavy user) recently arrived at a similar need, it seems.
 
> The other alternative is to run and count the tests at collect time:
> 1. Collector runs the cxxtests
> 2. Collector parses the test results and emits shadow tests that trivially fail, succeed or have an error.
> 3. Test runner runs the shadow tests.
> I am wary of running cxxtests during "collect", but I can't really say why.
>
> What do you think?

Right, it doesn't look completely fitting.  Running tests at collect time 
sounds wrong.  

If i were you I'd probably first try to collect one test item per test file and
parse the log/result file, raise a failure if anything failed and show details
if any test/assertion fails.   I'd probably first perfect this (including
properly and robustly parsing the log) and see how the resulting testing process
feels in practise.  The involved coding effort is worthwhile in any case.

If allowing multiple results still feels important maybe I can try / experiment
with the above idea (somehow allowing multiple results per one test item) 
or you could try this: a test run could create a cache file which will
be found by subsequent collections which will then create multiple items 
and not just one. The items can - at runtest() time - easily share the 
same result log from a cxx-run.  

cheers,
holger

P.S.: let's keep the discussion on py-dev as this may be interesting
for future reference or other people.

> Thanks so much for following up with this!!!
> 
> Eli
> 
> 
> 
> ________________________________________
> From: holger krekel [holger at merlinux.eu]
> Sent: Wednesday, October 27, 2010 11:52 PM
> To: Ateljevich, Eli
> Cc: py-dev at codespeak.net
> Subject: Re: [py-dev] py.test to control other testing framework
> 
> Hi Eli,
> 
> On Wed, Oct 27, 2010 at 17:00 -0700, Ateljevich, Eli wrote:
> > On another list, I asked Holger about how to use py.test as a wrapper to control non-python tests. He referred me to this example:
> > self-contained yaml example<http://codespeak.net/~hpk/pytest/example/nonpython.html>
> >
> > This got me going on the issue of collecting and running the tests.
> >
> > I have a follow-up question about aggregating results from these "foreign tests". I am using cxxunit, but the specifics are not important to my question. Each non-python test involves multiple asserts, failures and possibly errors. These test results could be reported in any of the usual formats (logs, stdout, JUnit xml format, custom).
> 
> (sidenote: I guess you are aware of the --junitxml option.)
> 
> > My question is this: is there a good way to track assert pass/fail counts correctly in py.test?
> >
> > One crude idea is to have cxxtest print out its assert attempts, passes and failures to a log, parse the log and then deliberately pass and fail a correct number of "shadow assertions" in python using the same log messages. Is there a more direct way?
> 
> Parsing a log sounds right.  However, there currently is no notion of "counting
> asserts" in py.test (or other popular python testing frameworks i am aware of).
> 
> Do you happen to have a way to find out the number of test functions/cases
> ahead of running a test file?  And to instruct cxxtest to run a particular
> function?
> 
> If so you could map cxx test functions to py.test Items and get
> more fine-granular "." printing and error representation.
> 
> Otherwise i guess you can only represent the whole cxxtest file as
> one test item.  Also because of other scenarios i am wondering how/if
> to help this situation, btw.
> 
> cheers,
> holger

-- 

From prologic at shortcircuit.net.au  Fri Oct 29 01:07:31 2010
From: prologic at shortcircuit.net.au (James Mills)
Date: Fri, 29 Oct 2010 09:07:31 +1000
Subject: [py-dev] py.test with setuptools
In-Reply-To: <20101028073436.GT11924@trillke.net>
References: <AANLkTi=oRMibmRCtuUojgBxTCbSARK+w44eMC-iaW7XB@mail.gmail.com>
	<20101028073436.GT11924@trillke.net>
Message-ID: <AANLkTinFrvn5t12P=uqFUhfLiorCSz=tk3h_Y9-4x3Z6@mail.gmail.com>

On Thu, Oct 28, 2010 at 5:34 PM, holger krekel <holger at merlinux.eu> wrote:
> I've written up an example of what i think is currently the best way
> to go about it for all distutils (or setuptools) based projects:
>
> ? ?http://codespeak.net/~hpk/pytest/goodpractises.html#integrating-with-distutils-python-setup-py-test
>
> Another option probably is to hack a bit deeper into setuptools and/or
> to wrap a py.test run into unittest "suites". ?The latter is maybe worth
> to try out but the above documented method is very solid and avoids hassles
> i think.

Thanks Holger, I'll look at both methods.

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

From morten.brekkevold at uninett.no  Mon Nov  1 21:47:30 2010
From: morten.brekkevold at uninett.no (Morten Brekkevold)
Date: Mon, 1 Nov 2010 21:47:30 +0100
Subject: [py-dev] Running Django unittests using py.test
Message-ID: <20101101204730.GA6418@uninett.no>

Hi,

We're using nose to run our test suite, but we are considering switching to
py.test.

Some of our tests inherit Django's django.test.TestCase. This class mucks
about with the test invocation machinery inherited from unittest.TestCase to
add simple support for loading of database fixtures (no need to use super()
calls to parent class' setUp/tearDown).

Unfortunately, all these tests will fail when run by py.test, whereas nose
runs thems fine.

After a quick look at the pytest_unittest plugin, it seems it does its own
tinkering and bypasses the normal way that unittest TestCases are invoked.
The setUp, test* and tearDown methods are called explicitly.  AFAIK, to
"manually" run a unittest.TestCase, you instantiate it using the desired test
method's name as an argument.  The resulting instance is callable; calling it
will take care of running setUp, the desired method and the tearDown.

Django's TestCase class hooks into this by overriding
unittest.TestCase.__call__(), and adds pre_setup and post_teardown hooks as
well.  Since py.test never uses TestCase instances as callables, Django
fixtures are never loaded and these tests fail.


I'm not familiar with the inner workings of py.test, so my question is: Is
this behavior intentional? If not, can we change it?


(this can be reproduced using http://dpaste.com/hold/268698/ - which doesn't
require Django, it just rips off Django's TestCase code)


-- 
Morten Brekkevold
UNINETT

From holger at merlinux.eu  Mon Nov  1 23:19:30 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 1 Nov 2010 23:19:30 +0100
Subject: [py-dev] improving unittest support (was: Re: Running
	Django	unittests using py.test)
In-Reply-To: <20101101204730.GA6418@uninett.no>
References: <20101101204730.GA6418@uninett.no>
Message-ID: <20101101221929.GM11924@trillke.net>

Hi Morten,

On Mon, Nov 01, 2010 at 21:47 +0100, Morten Brekkevold wrote:
> We're using nose to run our test suite, but we are considering switching to
> py.test.
> 
> Some of our tests inherit Django's django.test.TestCase. This class mucks
> about with the test invocation machinery inherited from unittest.TestCase to
> add simple support for loading of database fixtures (no need to use super()
> calls to parent class' setUp/tearDown).
> 
> Unfortunately, all these tests will fail when run by py.test, whereas nose
> runs thems fine.

Indeed, py.test (so far) only covers relatively plain 
unittest.TestCase usages.

> After a quick look at the pytest_unittest plugin, it seems it does its own
> tinkering and bypasses the normal way that unittest TestCases are invoked.
> The setUp, test* and tearDown methods are called explicitly.

Right.

> AFAIK, to "manually" run a unittest.TestCase, you instantiate it using the
> desired test method's name as an argument.  The resulting instance is
> callable; calling it will take care of running setUp, the desired method and
> the tearDown.

Originally the contributor (Guido Wesdorp) and me did this to maintain
py.test's own separation of setup/teardown/call phases IIRC.  

> Django's TestCase class hooks into this by overriding
> unittest.TestCase.__call__(), and adds pre_setup and post_teardown hooks as
> well.  Since py.test never uses TestCase instances as callables, Django
> fixtures are never loaded and these tests fail.

right.
 
> I'm not familiar with the inner workings of py.test, so my question is: Is
> this behavior intentional? If not, can we change it?

It is intentional but we can (try to) change it :)
 
> (this can be reproduced using http://dpaste.com/hold/268698/ - which doesn't
> require Django, it just rips off Django's TestCase code)

Thanks for providing the paste and your precise helpful info. 
As it happens i am in the process of preparing a pytest-2.0 and just
went ahead and changed the unittest-plugin to invoke the test case
as you described.  This lets your example run.   You can install it via::

    pip install -i http://pypi.testrun.org pytest

best in a virtualenv.  Typing "py.test --version" should 
give you at least 2.0.0.dev18

Does this work better for you?

sidenote: the unittest-plugin looks like this now::

    http://bitbucket.org/hpk42/pytest/src/tip/pytest/plugin/unittest.py

best,
holger


> 
> -- 
> Morten Brekkevold
> UNINETT
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 

From morten.brekkevold at uninett.no  Tue Nov  2 10:11:37 2010
From: morten.brekkevold at uninett.no (Morten Brekkevold)
Date: Tue, 2 Nov 2010 10:11:37 +0100
Subject: [py-dev] improving unittest support (was: Re: Running Django
 unittests using py.test)
In-Reply-To: <20101101221929.GM11924@trillke.net>
References: <20101101204730.GA6418@uninett.no>
	<20101101221929.GM11924@trillke.net>
Message-ID: <20101102091115.GA10005@uninett.no>

On Mon, Nov 01, 2010 at 11:19:30PM +0100, holger krekel wrote:
 
> > Django's TestCase class hooks into this by overriding
> > unittest.TestCase.__call__(), and adds pre_setup and post_teardown hooks as
> > well.  Since py.test never uses TestCase instances as callables, Django
> > fixtures are never loaded and these tests fail.
> 
> right.
>  
> > I'm not familiar with the inner workings of py.test, so my question is: Is
> > this behavior intentional? If not, can we change it?
> 
> It is intentional but we can (try to) change it :)

As long as the mentioned internal separation of the phases won't be a
problem. I'm sure you know best :)

> > (this can be reproduced using http://dpaste.com/hold/268698/ - which doesn't
> > require Django, it just rips off Django's TestCase code)
> 
> Thanks for providing the paste and your precise helpful info. 

No prob, I wrote that just to satisfy my curiosity.  Didn't want to start
tinkering with py.test code without knowing what I was doing, though.

> As it happens i am in the process of preparing a pytest-2.0 and just
> went ahead and changed the unittest-plugin to invoke the test case
> as you described.  This lets your example run.   

Wow, that was fast :-)

>     pip install -i http://pypi.testrun.org pytest
 
> Does this work better for you?

Definitely.  All tests pass with flying colors now, thank you very much.  Is
there an ETA on a 2.0 release?

-- 
mvh
Morten Brekkevold
UNINETT

From holger at merlinux.eu  Thu Nov  4 13:35:49 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 4 Nov 2010 13:35:49 +0100
Subject: [py-dev] improving unittest support (was: Re: Running
	Django	unittests using py.test)
In-Reply-To: <20101102091115.GA10005@uninett.no>
References: <20101101204730.GA6418@uninett.no>
	<20101101221929.GM11924@trillke.net>
	<20101102091115.GA10005@uninett.no>
Message-ID: <20101104123549.GP11924@trillke.net>

Hi Morten,

On Tue, Nov 02, 2010 at 10:11 +0100, Morten Brekkevold wrote:
> On Mon, Nov 01, 2010 at 11:19:30PM +0100, holger krekel wrote:
>  
> > > Django's TestCase class hooks into this by overriding
> > > unittest.TestCase.__call__(), and adds pre_setup and post_teardown hooks as
> > > well.  Since py.test never uses TestCase instances as callables, Django
> > > fixtures are never loaded and these tests fail.
> > 
> > right.
> >  
> > > I'm not familiar with the inner workings of py.test, so my question is: Is
> > > this behavior intentional? If not, can we change it?
> > 
> > It is intentional but we can (try to) change it :)
> 
> As long as the mentioned internal separation of the phases won't be a
> problem. I'm sure you know best :)

Let's hope so :)
 
> > > (this can be reproduced using http://dpaste.com/hold/268698/ - which doesn't
> > > require Django, it just rips off Django's TestCase code)
> > 
> > Thanks for providing the paste and your precise helpful info. 
> 
> No prob, I wrote that just to satisfy my curiosity.  Didn't want to start
> tinkering with py.test code without knowing what I was doing, though.

I am very interested in feedback and co-hacking on unittest support,
specifically.  I am not using unittest based test suites/cases myself
so i depend on support and "registered interest" on that front.

> > As it happens i am in the process of preparing a pytest-2.0 and just
> > went ahead and changed the unittest-plugin to invoke the test case
> > as you described.  This lets your example run.   
> 
> Wow, that was fast :-)
> 
> >     pip install -i http://pypi.testrun.org pytest
>  
> > Does this work better for you?
> 
> Definitely.  All tests pass with flying colors now, thank you very much.  Is
> there an ETA on a 2.0 release?

By end next week i plan to have at least a 2.0 beta out.

best,
holger


> -- 
> mvh
> Morten Brekkevold
> UNINETT
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 

From holger at merlinux.eu  Tue Nov 23 17:44:54 2010
From: holger at merlinux.eu (holger krekel)
Date: Tue, 23 Nov 2010 17:44:54 +0100
Subject: [py-dev] upcoming releases (and distro names)
Message-ID: <20101123164454.GU1009@trillke.net>

Hi all,

here is the new repositories and planned distribution packages:

    pytest-2.0  bb:pytest  (depends on >=py-1.4)
    pycmd-1.0   bb:pycmd   (depends on >=py-1.4)
    py-1.4      bb:py      (no dependencies)

The according code was previously contained in py==1.3.4
and the repository was bb:py-trunk which will cease
to be active.

You can install the most recent development version so 
e.g. "pytest" via this line::

    pip install -i http://pypi.testrun.org -U pytest
    pip install -i http://pypi.testrun.org -U pycmd
    ...

and i'd be happy to hear about problems as i plan
to release things real soon now (tm).

note: if you have used the intermediate packages from 
http://pypi.testrun.org then you may need to uninstall
"pylib" via e.g. "pip uninstall pylib" as i dropped
this packaging idea. KISS and all that.

cheers,
holger

From holger at merlinux.eu  Thu Nov 25 21:39:00 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 25 Nov 2010 21:39:00 +0100
Subject: [py-dev] pytest-2.0: asserts++, unittest++, reporting++, config++,
	docs++
Message-ID: <20101125203900.GC1009@trillke.net>

py.test 2.0.0: asserts++, unittest++, reporting++, config++, docs++
===========================================================================

Welcome to pytest-2.0.0, a major new release of "py.test", the rapid
easy Python testing tool.  There are many new features and enhancements,
see below for summary and detailed lists.  A lot of long-deprecated code
has been removed, resulting in a much smaller and cleaner implementation.  
See the new docs with examples here:

    http://pytest.org/

I also just released pytest-xdist-1.5, the plugin for distributed testing -
which was successfully used to speed up a real-life unittest suite 4-times written
for (twisted) trial, thanks to the generic unittest integration improvements.
See here for docs and install instructions:

    http://pypi.python.org/pypi?:action=display&name=pytest-xdist

A note on packaging: pytest used to part of the "py" distribution up
until version py-1.3.4 but this has changed now:  pytest-2.0.0 only
contains py.test related code and is expected to be backward-compatible
to existing test code. If you want to install pytest, just type one of::

    pip install -U pytest
    easy_install -U pytest

Many thanks to all issue reporters and people asking questions or
complaining.  Particular thanks to Floris Bruynooghe and Ronny Pfannschmidt
for their great coding contributions and many others for feedback and help.

best,
holger krekel


New Features
-----------------------

- new invocations through Python interpreter and from Python::

    python -m pytest      # on all pythons >= 2.5

  or from a python program::

    import pytest ; pytest.main(arglist, pluginlist)

  see http://pytest.org/2.0.0/usage.html for details.

- new and better reporting information in assert expressions
  if comparing lists, sequences or strings.

  see http://pytest.org/2.0.0/assert.html#newreport

- new configuration through ini-files (setup.cfg or tox.ini recognized),
  for example::

    [pytest]
    norecursedirs = .hg data*  # don't ever recurse in such dirs
    addopts = -x --pyargs      # add these command line options by default

  see http://pytest.org/2.0.0/customize.html

- improved standard unittest support.  In general py.test should now
  better be able to run custom unittest.TestCases like twisted trial
  or Django based TestCases.  Also you can now run the tests of an
  installed 'unittest' package with py.test::

    py.test --pyargs unittest

- new "-q" option which decreases verbosity and prints a more
  nose/unittest-style "dot" output.

- many many more detailed improvements details

Fixes
-----------------------

- fix issue126 - introduce py.test.set_trace() to trace execution via
  PDB during the running of tests even if capturing is ongoing.
- fix issue124 - make reporting more resilient against tests opening
  files on filedescriptor 1 (stdout).
- fix issue109 - sibling conftest.py files will not be loaded.
  (and Directory collectors cannot be customized anymore from a Directory's
  conftest.py - this needs to happen at least one level up).
- fix issue88 (finding custom test nodes from command line arg)
- fix issue93 stdout/stderr is captured while importing conftest.py
- fix bug: unittest collected functions now also can have "pytestmark"
  applied at class/module level

Important Notes
--------------------

* The usual way in pre-2.0 times to use py.test in python code was
  to import "py" and then e.g. use "py.test.raises" for the helper.
  This remains valid and is not planned to be deprecated.  However,
  in most examples and internal code you'll find "import pytest"
  and "pytest.raises" used as the recommended default way.

* pytest now first performs collection of the complete test suite
  before running any test. This changes for example the semantics of when
  pytest_collectstart/pytest_collectreport are called.  Some plugins may
  need upgrading.

* The pytest package consists of a 400 LOC core.py and about 20 builtin plugins,
  summing up to roughly 5000 LOCs, including docstrings. To be fair, it also
  uses generic code from the "pylib", and the new "py" package to help
  with filesystem and introspection/code manipulation.

(Incompatible) Removals
-----------------------------

- py.test.config is now only available if you are in a test run.

- the following (mostly already deprecated) functionality was removed:

  - removed support for Module/Class/... collection node definitions
    in conftest.py files.  They will cause nothing special.
  - removed support for calling the pre-1.0 collection API of "run()" and "join"
  - removed reading option values from conftest.py files or env variables.
    This can now be done much much better and easier through the ini-file
    mechanism and the "addopts" entry in particular.
  - removed the "disabled" attribute in test classes.  Use the skipping
    and pytestmark mechanism to skip or xfail a test class.

- py.test.collect.Directory does not exist anymore and it
  is not possible to provide an own "Directory" object.
  If you have used this and don't know what to do, get
  in contact.  We'll figure someting out.

  Note that pytest_collect_directory() is still called but
  any return value will be ignored.  This allows to keep
  old code working that performed for example "py.test.skip()"
  in collect() to prevent recursion into directory trees
  if a certain dependency or command line option is missing.


see :ref:`changelog` for more detailed changes.
-- 

From holger at merlinux.eu  Thu Nov 25 21:54:36 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 25 Nov 2010 21:54:36 +0100
Subject: [py-dev] tox-0.9: better CI bootstrapping / custom PyPI index
	servers
Message-ID: <20101125205436.GD1009@trillke.net>

Hi all, 

i just released tox-0.9, the generic virtualenv-using test integration 
automation tool (tm).  This release brings a new zero-install way to
deploy tox and your test suite on Hudson slaves.  Apart from one or
more Python interpreters you do not need anything on the slave side,
see here for details:

    http://codespeak.net/tox/example/hudson.html#zero-installation-for-slaves

Moreover, you can now work with multiple PyPI index servers which
is very nice if you (want to) operate your own in-company servers, 
see here for details:

    http://codespeak.net/tox/example/basic.html#using-a-different-default-pypi-url

Btw, what kind of custom servers are you successfully using? 
(tell me on twitter @hpk42 if you like).

Oh, and for basic info just go to

    http://codespeak.net/tox

if that wasn't clear yet.

have fun,
holger

Changelog for 0.9
-----------------------

- added support for working with different and multiple PYPI indexservers.
- fix pip-installation mixups by always unsetting PIP_RESPECT_VIRTUALENV
  (thanks Armin Ronacher)
- issue1: Add a toxbootstrap.py script for tox, thanks to Sridhar Ratnakumar
- new option: -r|--recreate to force recreation of virtualenv
- show logfile content if there is an error (makes CI output
  more readable)
- depend on py>=1.4.0 which does not contain or install the py.test
  anymore which is now a separate distribution "pytest".

From holger at merlinux.eu  Fri Nov 26 09:42:49 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 26 Nov 2010 09:42:49 +0100
Subject: [py-dev] [TIP] pytest-2.0: asserts++, unittest++, reporting++,
	config++, docs++
In-Reply-To: <AANLkTinM4oOQvJvvo1JiS=ENJZf5bRmaSETbizd5p4=-@mail.gmail.com>
References: <20101125203900.GC1009@trillke.net>
	<AANLkTi=9Ar52ku2NP1hUjsbagTu3WVxB+bpH7gw05ZTG@mail.gmail.com>
	<AANLkTinM4oOQvJvvo1JiS=ENJZf5bRmaSETbizd5p4=-@mail.gmail.com>
Message-ID: <20101126084249.GE1009@trillke.net>

Hi Phlip,

On Thu, Nov 25, 2010 at 17:05 -0800, Phlip wrote:
> > I am now converting my brand-new, blue-sky, make-or-break project to
> > use your tester. Don't let me down!

Heh, i'd like to help, am always looking for real-world feedback
and issues :)
 
> Aaand, i would prefer to migrate case-by case. Is there some way to
> invoke a single suite, such as from within the Django test runner?
> 
> I'm trying the hard way - throwing everything to pytest via "pip
> install django-pytest", but I get this mess:

haven't used or tested django-pytest myself ...
The below error seems to indicate pytest is not installed. 
Maybe django-pytest does not require it and you need to 
install pytest manually? 

As to your case-by-case strategy: what happens if you simply
run "py.test" (2.0) on your code base today? 

cheers,
holger

P.S.: I am often at #pylib on irc.freenode.net
where we could sort out things a bit more realtime.
Otherwise let's stick to one mailing list, i am fine with 
sticking to just TIP and to take things to private mail
if we have more than a couple of to and fros.

> [localhost] run: python manage.py test --settings=settings.test --verbosity=0
> Traceback (most recent call last):
>   File "manage.py", line 11, in <module>
>     execute_manager(settings)
>   File "/usr/lib/pymodules/python2.6/django/core/management/__init__.py",
> line 438, in execute_manager
>     utility.execute()
>   File "/usr/lib/pymodules/python2.6/django/core/management/__init__.py",
> line 379, in execute
>     self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/usr/lib/pymodules/python2.6/django/core/management/base.py",
> line 191, in run_from_argv
>     self.execute(*args, **options.__dict__)
>   File "/usr/lib/pymodules/python2.6/django/core/management/base.py",
> line 220, in execute
>     output = self.handle(*args, **options)
>   File "/usr/local/lib/python2.6/dist-packages/django_pytest/management/commands/test.py",
> line 40, in handle
>     super(Command, self).handle(*args, **kwargs)
>   File "/usr/lib/pymodules/python2.6/django/core/management/commands/test.py",
> line 34, in handle
>     failures = TestRunner(test_labels, verbosity=verbosity,
> interactive=interactive)
>   File "/usr/local/lib/python2.6/dist-packages/django_pytest/test_runner.py",
> line 7, in run_tests
>     load_entry_point('py>=1.0.0', 'console_scripts', 'py.test')()
>   File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 305,
> in load_entry_point
>     return get_distribution(dist).load_entry_point(group, name)
>   File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 2243,
> in load_entry_point
>     raise ImportError("Entry point %r not found" % ((group,name),))
> ImportError: Entry point ('console_scripts', 'py.test') not found
> 
> Uh, I did all the things this said to:
> http://pypi.python.org/pypi/django-pytest/0.1.4
> 
> Except I didn't call from py.test. If I had, I suspect I would not
> achieve migrate case by case, which is more important to me because my
> fixtures are somewhat elaborate!
> 
> -- 
> ? Phlip
> ? http://c2.com/cgi/wiki?ZeekLand
> 

-- 

From samuele.pedroni at gmail.com  Sun Nov 28 16:35:48 2010
From: samuele.pedroni at gmail.com (Samuele Pedroni)
Date: Sun, 28 Nov 2010 16:35:48 +0100
Subject: [py-dev] oejskit 0.8.9, javascript testing support,
	consolidation release
In-Reply-To: <AANLkTi=aGjjNr9Hzmqj58yDyNgh62VFrunueAn8x6ef+@mail.gmail.com>
References: <AANLkTi=aGjjNr9Hzmqj58yDyNgh62VFrunueAn8x6ef+@mail.gmail.com>
Message-ID: <AANLkTin9NGym3V=U1e4jSpNhrLRim+rJcxGWC2P4PEXa@mail.gmail.com>

I have just uploaded to pypi a new release 0.8.9 of oejskit, this is
just a consolidation release.

The main changes it that it is packaged as source tarball, making it
easier to install with Python 2.7, and that it drops support for
Python 2.5.

This release doesn't support yet py.test 2.0, I have started
investigating what is required to support it, it is not a completely
straightforward to port the plugin because browser and test session
management need to be intertwined, it will take a bit of time to
release something working with it.

unittest.py support is working and unchanged.

About OE jskit:

jskit contains infrastructure and in particular a py.test plugin to
enable running unit tests for JavaScript code inside browsers.
It contains also glue code to run JavaScript tests from unittest.py
based test suites.

The approach also enables to write integration tests such that the
JavaScript code is tested against server-side Python code mocked as
necessary. Any server-side framework that can already be exposed through
WSGI can play.

The plugin requires py.test 1.3.4 or slightly older.

More information and downloading at:

http://pypi.python.org/pypi/oejskit

including a changelog and ?documentation.

regards, Samuele Pedroni

From holger at merlinux.eu  Mon Nov 29 16:20:05 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 29 Nov 2010 16:20:05 +0100
Subject: [py-dev] py.test api - Running tests in a module object?
In-Reply-To: <10C7D726-EFFB-42F4-902C-D023A20FE498@activestate.com>
References: <4C5B2316.7050909@activestate.com>
	<20100805210652.GY1914@trillke.net>
	<4C5B2BF7.8070107@activestate.com>
	<20100805212823.GB1914@trillke.net>
	<10C7D726-EFFB-42F4-902C-D023A20FE498@activestate.com>
Message-ID: <20101129152005.GS1009@trillke.net>

On Thu, Aug 05, 2010 at 14:39 -0700, Sridhar Ratnakumar wrote:
> 
> On 2010-08-05, at 2:28 PM, holger krekel wrote:
> 
> > On Thu, Aug 05, 2010 at 14:24 -0700, Sridhar Ratnakumar wrote:
> >> On 8/5/2010 2:06 PM, holger krekel wrote:
> >>> On Thu, Aug 05, 2010 at 13:46 -0700, Sridhar Ratnakumar wrote:
> >>>>> I am trying to run py.test on a given module object dynamically.
> >>>>> 
> >>>>>       mod = __import__('company.foo.somemod')
> >>>>>       py.test.run(mod)
> >>>>> 
> >>>>> A quick glance in the py.test source doesn't seem like a trivial thing.
> >>>>> IPython introspection did not give me any clue either.
> >>>>> 
> >>>>> Is there a way to do this at all? I did try
> >>>>> py.test.cmdline.main(['...']), but that accepts only file path, not the
> >>>>> Python module object itself.
> >>> there currently is no direct support for running tests in python modules.
> >>> py.test basically always starts from the file system. Does it help you
> >>> to try to fish the file from somemod.__file__ and pass this to cmdline.main()?
> >>> You only expect it to collect tests of a single module, right?
> >>> I guess we could add some more direct support for this if
> >>> you continue to have the need (please create an issue if so).
> >> 
> >> Hmm, __file__ is a workaround, but it seems to work fine for my use  
> >> case. I was just wondering if an API was exposed.
> >> 
> >> I am happy with __file__ for now.
> > 
> > What do you think about automating this lookup and allowing
> > 
> >    py.test.cmdline.main([module])
> > 
> > maybe that's enough? 
> 
> 
> That might have helped, but then - just now, I rewrote some routines in my code to simply rely on .py file paths instead of modules. This simplified the code a bit. So now I have come to prefer file paths. :-) If I ever have the need for running tests on module/class/collection-of-funcs objects, I will be sure to open a feature request. Thanks.

FYI py.test-2.0 now supports the "--pyargs" option:

    py.test --pyargs company.foo.somemod

so that this will discover the __file__'s directory and collect tests there.
You can make this permanent, see here:
http://pytest.org/customize.html#adding-default-options

cheers,
holger

From flub at devork.be  Mon Nov 29 23:38:29 2010
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 29 Nov 2010 22:38:29 +0000
Subject: [py-dev] Adding a funcarg to pytest_capturelog plugin
Message-ID: <AANLkTimWznEUbmq=JKUL7kDjSB=G2U-JGFrhxphLd_7U@mail.gmail.com>

Hi Meme

Your capturelog plugin for py.test is very useful, thanks for writing
it!  But recently I've had the need to be able to modify the recorded
loglevel inside the test (or during test setup) mostly to temporarily
silence the logging.  For this I added a funcarg named "capturelog"
which exposes the loghandler (wrapped so it can be used as a context
manager too) which seems like a fairly nice way to work.  The only
ugly part of this is that I had to store the loghandler instance on
the function instance as well instead of just on the item.

The second thing I wanted to do was to be able to assert on the
contents of log messages, specifically I wanted to ensure there where
no critical messages logged.  Having the above funcarg already it
seemed most logical to just add this to the same loghandler already
used by overwriting the .emit() method to store the raw LogRecord
instances.  I guess you could argue as to weather the list of
LogRecord instances or the entire py.io.TextIO version of log should
be made available, but I preferred the former.

I've cloned your repository at
http://bitbucket.org/flub/pytest-capturelog/ to add this
functionality, the changes should be pretty simple and obvious.  I
think it could be useful if you could merge a version of this.  Let me
know if you have remarks or would like to see things slightly
differently.

Lastly, while talking on #pylib (IRC) to Holger he mentioned that he
wondered if it would be worth to include the capturelog extension as a
default plugin in py.test since it is to cooperate with a stdlib
module.  So if you also think this is interesting you might like to
discuss this with him.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From memedough at gmail.com  Sun Dec  5 10:41:26 2010
From: memedough at gmail.com (meme dough)
Date: Sun, 5 Dec 2010 20:41:26 +1100
Subject: [py-dev] pytest-capturelog plugin 0.6
Message-ID: <AANLkTikNEQoTo5o-fUpKgbj81-1k=Wh-WHWc9mAdQ-8D@mail.gmail.com>

Hi,

Thanks to Floris the capturelog plugin now has a funcarg that allows
adjusting the log levels and provides access to log records and the
log text.

:)

From holger at merlinux.eu  Mon Dec  6 14:46:10 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 6 Dec 2010 14:46:10 +0100
Subject: [py-dev] pytest-pep8 0.6: configurable PEP8 checking in py.test runs
Message-ID: <20101206134610.GO1009@trillke.net>


just released an initial version 0.6 of the pytest-pep8 plugin, 
integrating the ``pep8`` module into py.test runs, allowing full
per-project customization and configuration. 

See http://pypi.python.org/pypi/pytest-pep8 for installation
and configuration instructions.

best,
holger

Usage
-----------------

install pytest-pep8 via::

    easy_install pytest-pep8 # or
    pip install pytest-pep8

and then type::

    py.test --pep8
    
to activate source code checking. Every file ending in ``.py`` will be
discovered and checked, starting from the command line arguments.
For example, if you have a file like this::

    # content of myfile.py
 
    somefunc( 123,456)

you can run it with::

    $ py.test --pep8
    =========================== test session starts ============================
    platform linux2 -- Python 2.6.5 -- pytest-2.0.1.dev1
    pep8 ignore opts: E202 E221 E222 E241 E301 E302 E401 E501 E701 W293 W391 W601 W602
    collecting ... collected 1 items
    
    myfile.py F
    
    ================================= FAILURES =================================
    ________________________________ PEP8-check ________________________________
    /tmp/doc-exec-12/myfile.py:2:10: E201 whitespace after '('
    somefunc( 123,456)
             ^
    /tmp/doc-exec-12/myfile.py:2:14: E231 missing whitespace after ','
    somefunc( 123,456)
                 ^
    
    ========================= 1 failed in 0.01 seconds =========================

Note that in the testing header you see the current list of default "ignores".
For the meaning of these error and warning codes, see the error output
when running against your files or checkout `pep8.py
<https://github.com/jcrocholl/pep8/blob/master/pep8.py>`_.

Configuring PEP8 options per-project
---------------------------------------------

Lastly, you may configure PEP8-checking options for your project
by adding an ``pep8options`` entry to your ``pytest.ini``
or ``setup.cfg`` file like this::

    [pytest]
    pep8options = +W293 -E200


Running PEP8 checks and no other tests
---------------------------------------------

You can also restrict your test run to only perform "pep8" tests
and not any other tests by typing::

    py.test --pep8 -k pep8

This will only run tests that are marked with the "pep8" keyword
which is added for the pep8 test items added by this plugin.

Notes
-------------

The repository of this plugin is at http://bitbucket.org/hpk42/pytest-pep8

For more info on py.test see http://pytest.org

The code is partially based on Ronny Pfannschmidt's pytest-codecheckers plugin.


From holger at merlinux.eu  Mon Dec  6 15:50:16 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 6 Dec 2010 15:50:16 +0100
Subject: [py-dev] [TIP] pytest-pep8 0.6: configurable PEP8 checking in
	py.test	runs
In-Reply-To: <AANLkTi=0PqgrB74uT-J9M3j72w+SRm1q0LR55DkoZW2H@mail.gmail.com>
References: <20101206134610.GO1009@trillke.net>
	<AANLkTi=0PqgrB74uT-J9M3j72w+SRm1q0LR55DkoZW2H@mail.gmail.com>
Message-ID: <20101206145015.GP1009@trillke.net>

On Mon, Dec 06, 2010 at 09:00 -0500, Alfredo Deza wrote:
> On Mon, Dec 6, 2010 at 8:46 AM, holger krekel <holger at merlinux.eu> wrote:
> 
> >
> > just released an initial version 0.6 of the pytest-pep8 plugin,
> > integrating the ``pep8`` module into py.test runs, allowing full
> > per-project customization and configuration.
> >
> >
> This looks very useful as py.test plugin.
> 
> Is there any way of getting junit output from it? This would help when using
> it with Hudson.
> 
> We already use the junit flag to output test results but wanted to add
> something like the pep8 plugin
> for correctness :)

Heh, <borrowing-time-machine> actually

    py.test --pep8 --junitxml=mypath.xml

should present all PEP8 errors or warnings in the JunitXML file.
If not, i'd consider it a bug which you can report or fix
with the http://bitbucket.org/hpk42/pytest-pep8 repo.

sidenote: i am not sure about the default behaviour - would it 
maybe make sense to start out with warning/erroring on everything
and leaving it to project-specific configuration which warnings
and pep8 errors to ignore?

cheers,
holger
 
> 
> 
> 
> > See http://pypi.python.org/pypi/pytest-pep8 for installation
> > and configuration instructions.
> >
> > best,
> > holger
> >
> > Usage
> > -----------------
> >
> > install pytest-pep8 via::
> >
> >    easy_install pytest-pep8 # or
> >    pip install pytest-pep8
> >
> > and then type::
> >
> >    py.test --pep8
> >
> > to activate source code checking. Every file ending in ``.py`` will be
> > discovered and checked, starting from the command line arguments.
> > For example, if you have a file like this::
> >
> >    # content of myfile.py
> >
> >    somefunc( 123,456)
> >
> > you can run it with::
> >
> >    $ py.test --pep8
> >    =========================== test session starts
> > ============================
> >    platform linux2 -- Python 2.6.5 -- pytest-2.0.1.dev1
> >    pep8 ignore opts: E202 E221 E222 E241 E301 E302 E401 E501 E701 W293 W391
> > W601 W602
> >    collecting ... collected 1 items
> >
> >    myfile.py F
> >
> >    ================================= FAILURES
> > =================================
> >    ________________________________ PEP8-check
> > ________________________________
> >    /tmp/doc-exec-12/myfile.py:2:10: E201 whitespace after '('
> >    somefunc( 123,456)
> >             ^
> >    /tmp/doc-exec-12/myfile.py:2:14: E231 missing whitespace after ','
> >    somefunc( 123,456)
> >                 ^
> >
> >    ========================= 1 failed in 0.01 seconds
> > =========================
> >
> > Note that in the testing header you see the current list of default
> > "ignores".
> > For the meaning of these error and warning codes, see the error output
> > when running against your files or checkout `pep8.py
> > <https://github.com/jcrocholl/pep8/blob/master/pep8.py>`_.
> >
> > Configuring PEP8 options per-project
> > ---------------------------------------------
> >
> > Lastly, you may configure PEP8-checking options for your project
> > by adding an ``pep8options`` entry to your ``pytest.ini``
> > or ``setup.cfg`` file like this::
> >
> >    [pytest]
> >    pep8options = +W293 -E200
> >
> >
> > Running PEP8 checks and no other tests
> > ---------------------------------------------
> >
> > You can also restrict your test run to only perform "pep8" tests
> > and not any other tests by typing::
> >
> >    py.test --pep8 -k pep8
> >
> > This will only run tests that are marked with the "pep8" keyword
> > which is added for the pep8 test items added by this plugin.
> >
> > Notes
> > -------------
> >
> > The repository of this plugin is at http://bitbucket.org/hpk42/pytest-pep8
> >
> > For more info on py.test see http://pytest.org
> >
> > The code is partially based on Ronny Pfannschmidt's pytest-codecheckers
> > plugin.
> >
> >
> > _______________________________________________
> > testing-in-python mailing list
> > testing-in-python at lists.idyll.org
> > http://lists.idyll.org/listinfo/testing-in-python
> >

-- 

From holger at merlinux.eu  Mon Dec  6 16:42:30 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 6 Dec 2010 16:42:30 +0100
Subject: [py-dev] pytest-pep 0.7: check everything,
	determine your own PEP8 ignorance
In-Reply-To: <AANLkTim7S+LecUcd6M9jEBx97J_u6fVWGKKEUFG5r0Zg@mail.gmail.com>
References: <20101206134610.GO1009@trillke.net>
	<AANLkTi=0PqgrB74uT-J9M3j72w+SRm1q0LR55DkoZW2H@mail.gmail.com>
	<20101206145015.GP1009@trillke.net>
	<AANLkTim7S+LecUcd6M9jEBx97J_u6fVWGKKEUFG5r0Zg@mail.gmail.com>
Message-ID: <20101206154230.GR1009@trillke.net>

Hi Alfredo,

thanks for the feedback.  i released pytest-pep8 0.7 now which has a 

    [pytest]
    pep8ignore  = OPT1 OPT2 ...

option so that you can make up project specific list, starting now
with a "check everything" setting.  I updated the docs as well, see 

    http://pypi.python.org/pypi/pytest-pep8

cheers,
holger

On Mon, Dec 06, 2010 at 09:55 -0500, Alfredo Deza wrote:
> On Mon, Dec 6, 2010 at 9:50 AM, holger krekel <holger at merlinux.eu> wrote:
> 
> > On Mon, Dec 06, 2010 at 09:00 -0500, Alfredo Deza wrote:
> > > On Mon, Dec 6, 2010 at 8:46 AM, holger krekel <holger at merlinux.eu>
> > wrote:
> > >
> > > >
> > > > just released an initial version 0.6 of the pytest-pep8 plugin,
> > > > integrating the ``pep8`` module into py.test runs, allowing full
> > > > per-project customization and configuration.
> > > >
> > > >
> > > This looks very useful as py.test plugin.
> > >
> > > Is there any way of getting junit output from it? This would help when
> > using
> > > it with Hudson.
> > >
> > > We already use the junit flag to output test results but wanted to add
> > > something like the pep8 plugin
> > > for correctness :)
> >
> > Heh, <borrowing-time-machine> actually
> >
> >    py.test --pep8 --junitxml=mypath.xml
> >
> > should present all PEP8 errors or warnings in the JunitXML file.
> > If not, i'd consider it a bug which you can report or fix
> > with the http://bitbucket.org/hpk42/pytest-pep8 repo.
> >
> 
> Ok great, so no "extras" are involved to make it output to the JunitXML
> file. Nice.
> 
> >
> > sidenote: i am not sure about the default behaviour - would it
> > maybe make sense to start out with warning/erroring on everything
> > and leaving it to project-specific configuration which warnings
> > and pep8 errors to ignore?
> >
> 
> I think it is safe to assume that if you are using this plugin you want
> everything
> "ON" by default, so you can see what things you are interested in and tweak
> (turn off)
> as you progress.
> 
> >
> > cheers,
> > holger
> >
> > >
> > >
> > >
> > > > See http://pypi.python.org/pypi/pytest-pep8 for installation
> > > > and configuration instructions.
> > > >
> > > > best,
> > > > holger
> > > >
> > > > Usage
> > > > -----------------
> > > >
> > > > install pytest-pep8 via::
> > > >
> > > >    easy_install pytest-pep8 # or
> > > >    pip install pytest-pep8
> > > >
> > > > and then type::
> > > >
> > > >    py.test --pep8
> > > >
> > > > to activate source code checking. Every file ending in ``.py`` will be
> > > > discovered and checked, starting from the command line arguments.
> > > > For example, if you have a file like this::
> > > >
> > > >    # content of myfile.py
> > > >
> > > >    somefunc( 123,456)
> > > >
> > > > you can run it with::
> > > >
> > > >    $ py.test --pep8
> > > >    =========================== test session starts
> > > > ============================
> > > >    platform linux2 -- Python 2.6.5 -- pytest-2.0.1.dev1
> > > >    pep8 ignore opts: E202 E221 E222 E241 E301 E302 E401 E501 E701 W293
> > W391
> > > > W601 W602
> > > >    collecting ... collected 1 items
> > > >
> > > >    myfile.py F
> > > >
> > > >    ================================= FAILURES
> > > > =================================
> > > >    ________________________________ PEP8-check
> > > > ________________________________
> > > >    /tmp/doc-exec-12/myfile.py:2:10: E201 whitespace after '('
> > > >    somefunc( 123,456)
> > > >             ^
> > > >    /tmp/doc-exec-12/myfile.py:2:14: E231 missing whitespace after ','
> > > >    somefunc( 123,456)
> > > >                 ^
> > > >
> > > >    ========================= 1 failed in 0.01 seconds
> > > > =========================
> > > >
> > > > Note that in the testing header you see the current list of default
> > > > "ignores".
> > > > For the meaning of these error and warning codes, see the error output
> > > > when running against your files or checkout `pep8.py
> > > > <https://github.com/jcrocholl/pep8/blob/master/pep8.py>`_.
> > > >
> > > > Configuring PEP8 options per-project
> > > > ---------------------------------------------
> > > >
> > > > Lastly, you may configure PEP8-checking options for your project
> > > > by adding an ``pep8options`` entry to your ``pytest.ini``
> > > > or ``setup.cfg`` file like this::
> > > >
> > > >    [pytest]
> > > >    pep8options = +W293 -E200
> > > >
> > > >
> > > > Running PEP8 checks and no other tests
> > > > ---------------------------------------------
> > > >
> > > > You can also restrict your test run to only perform "pep8" tests
> > > > and not any other tests by typing::
> > > >
> > > >    py.test --pep8 -k pep8
> > > >
> > > > This will only run tests that are marked with the "pep8" keyword
> > > > which is added for the pep8 test items added by this plugin.
> > > >
> > > > Notes
> > > > -------------
> > > >
> > > > The repository of this plugin is at
> > http://bitbucket.org/hpk42/pytest-pep8
> > > >
> > > > For more info on py.test see http://pytest.org
> > > >
> > > > The code is partially based on Ronny Pfannschmidt's pytest-codecheckers
> > > > plugin.
> > > >
> > > >
> > > > _______________________________________________
> > > > testing-in-python mailing list
> > > > testing-in-python at lists.idyll.org
> > > > http://lists.idyll.org/listinfo/testing-in-python
> > > >
> >
> > --
> >

-- 

From andy.fundinger at riskfocusinc.com  Mon Dec  6 22:20:35 2010
From: andy.fundinger at riskfocusinc.com (Andy Fundinger)
Date: Mon, 6 Dec 2010 16:20:35 -0500 (EST)
Subject: [py-dev] Upgrading from pytest 1.3.2 to 2.0 - computed conftest
	options
Message-ID: <752301.198.1291670435078.JavaMail.root@ip-208-109-234-141.ip.secureserver.net>

I'm trying to upgrade from py.test 1.3.2 to 2.0 but I'm running into 
issues with my use of the old style conftest.py feature to specify 
options.  I specify options like:


option_cov_branch = True 

option_cov_data_file = os.path.join(os.environ["PROJECT_ROOT"],"testCovFile%d.log"%random.randint(0,100000))

option_tx = ["popen//python=python",]*multiprocessing.cpu_count()


the computed ones are a problem as the new .ini files can't take them 
and the conftest.py file specification seems to be ignored.  Is there a 
particular hook that I can grab and add/change config values early 
enough to affect all plugins?




Regards,

Andy Fundinger

Risk Focus Inc.
424.243.6227


New York  Office: +1 917 725 6006  Fax: +1 917 591 1616

London  Office: +44 (0) 207 760 7184  Fax: +44 (0) 207 691 7165
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20101206/c03664b4/attachment.htm 

From holger at merlinux.eu  Tue Dec  7 12:31:27 2010
From: holger at merlinux.eu (holger krekel)
Date: Tue, 7 Dec 2010 12:31:27 +0100
Subject: [py-dev] Upgrading from pytest 1.3.2 to 2.0 - computed	conftest
	options
In-Reply-To: <752301.198.1291670435078.JavaMail.root@ip-208-109-234-141.ip.secureserver.net>
References: <752301.198.1291670435078.JavaMail.root@ip-208-109-234-141.ip.secureserver.net>
Message-ID: <20101207113127.GU1009@trillke.net>

Hi Andy,

On Mon, Dec 06, 2010 at 16:20 -0500, Andy Fundinger wrote:
> I'm trying to upgrade from py.test 1.3.2 to 2.0 but I'm running into 
> issues with my use of the old style conftest.py feature to specify 
> options.  I specify options like:
> 
> 
> option_cov_branch = True 
> 
> option_cov_data_file = os.path.join(os.environ["PROJECT_ROOT"],"testCovFile%d.log"%random.randint(0,100000))
> 
> option_tx = ["popen//python=python",]*multiprocessing.cpu_count()
> 
> 
> the computed ones are a problem as the new .ini files can't take them 
> and the conftest.py file specification seems to be ignored.  Is there a 
> particular hook that I can grab and add/change config values early 
> enough to affect all plugins?

Indeed a feature regression.  I just added a new pytest_cmdline_processargs
hook to accomodate the situation.  The basic idea is to add command line 
arguments before option parsing takes place.  It is only called on the 
master.  The slaves do not call this hook.  

It's not released yet but you can see an example in the upcoming docs here:

    http://pytest.org/2.0.1dev/example/simple.html#dynamically-adding-command-line-options

and install the the development version with::

    pip install -i http://pypi.testrun.org -U pytest

Let me know of any issues.  A note already though: i think the pytest-cov plugin 
does not provide the options you use above.  Instead it uses/allows to point
to a .coveragerc file.  I believe it also cares for coverage data filenames
itself.

cheers,
holger
 
> 
> 
> 
> Regards,
> 
> Andy Fundinger
> 
> Risk Focus Inc.
> 424.243.6227
> 
> 
> New York  Office: +1 917 725 6006  Fax: +1 917 591 1616
> 
> London  Office: +44 (0) 207 760 7184  Fax: +44 (0) 207 691 7165
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev


-- 

From holger at merlinux.eu  Tue Dec  7 12:39:24 2010
From: holger at merlinux.eu (holger krekel)
Date: Tue, 7 Dec 2010 12:39:24 +0100
Subject: [py-dev] Upgrading from pytest 1.3.2 to 2.0 - computed
	conftest	options
In-Reply-To: <20101207113127.GU1009@trillke.net>
References: <752301.198.1291670435078.JavaMail.root@ip-208-109-234-141.ip.secureserver.net>
	<20101207113127.GU1009@trillke.net>
Message-ID: <20101207113924.GV1009@trillke.net>

On Tue, Dec 07, 2010 at 12:31 +0100, holger krekel wrote:
> I just added a new pytest_cmdline_processargs
> hook to accomodate the situation.  

Actually it's called pytest_cmdline_preparse.
And btw, you might want to also upgrade pytest-xdist via

    pip install -U pytest-xdist -i http://pypi.testrun.org

(which will drag along pytest-2.0.1.dev5 i guess)
H.

From andy.fundinger at riskfocusinc.com  Fri Dec 10 15:17:17 2010
From: andy.fundinger at riskfocusinc.com (Andy Fundinger)
Date: Fri, 10 Dec 2010 09:17:17 -0500 (EST)
Subject: [py-dev] Internal Error in xdist remove
Message-ID: <10088290.959.1291990637762.JavaMail.root@ip-208-109-234-141.ip.secureserver.net>

Continuing my attempted upgrade to pytest 2.0.0 I'm running into some errors with using xdist for parallel testing, this test is meant to run on two local nodes in parallel and boxed, but somehow it's trying to remove something that isn't there.  Any ideas?  The full log is below with a few bits removed because they reference my source code, if they're critical I can obscure the data rather than removing them or try to reproduce with non-project code.


Andy Fundinger



scheduling tests via LoadScheduling
INTERNALERROR> config = <_pytest.config.Config object
at 0xff22a90>
INTERNALERROR>
INTERNALERROR>     def
pytest_cmdline_main(config):
INTERNALERROR>        
""" default command line protocol for initialization, session,
INTERNALERROR>        
running tests and reporting. """
INTERNALERROR>        
session = Session(config)
INTERNALERROR>        
session.exitstatus = EXIT_OK
INTERNALERROR>        
try:
INTERNALERROR>            
config.pluginmanager.do_configure(config)
INTERNALERROR>            
config.hook.pytest_sessionstart(session=session)
INTERNALERROR>            
config.hook.pytest_collection(session=session)
INTERNALERROR> >           config.hook.pytest_runtestloop(session=session)
INTERNALERROR>
INTERNALERROR> config     =
<_pytest.config.Config object at 0xff22a90>
INTERNALERROR> session    = <Session
'gauss_tools'>
INTERNALERROR>
INTERNALERROR> 
/home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest-2.0.1.dev5-py2.6.egg/_pytest/main.py:65:
INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
INTERNALERROR>
INTERNALERROR> self = <HookCaller
'pytest_runtestloop'>
INTERNALERROR>
INTERNALERROR>     def __call__(self,
**kwargs):
INTERNALERROR>        
methods = self.hookrelay._pm.listattr(self.name)
INTERNALERROR> >      
return self._docall(methods, kwargs)
INTERNALERROR>
INTERNALERROR> kwargs     =
{'session': <Session 'gauss_tools'>}
INTERNALERROR> methods    = [<function
pytest_runtestloop at 0x1001b758>, <bound method
DSession.pytest_runtestloop of <xdist.dsession.DSession instance at
0x180b5368>>]
INTERNALERROR> self       =
<HookCaller 'pytest_runtestloop'>
INTERNALERROR>
INTERNALERROR>
/home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest-2.0.1.dev5-py2.6.egg/_pytest/core.py:390:
INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
INTERNALERROR>
INTERNALERROR> self = <HookCaller
'pytest_runtestloop'>
INTERNALERROR> methods = [<function pytest_runtestloop
at 0x1001b758>, <bound method DSession.pytest_runtestloop of
<xdist.dsession.DSession instance at 0x180b5368>>]
INTERNALERROR> kwargs = {'session': <Session
'gauss_tools'>}
INTERNALERROR>
INTERNALERROR>     def _docall(self,
methods, kwargs):
INTERNALERROR>        
self.trace(self.name, kwargs)
INTERNALERROR>        
self.trace.root.indent += 1
INTERNALERROR>        
mc = MultiCall(methods, kwargs, firstresult=self.firstresult)
INTERNALERROR>        
try:
INTERNALERROR>
>           res =
mc.execute()
INTERNALERROR>
INTERNALERROR> kwargs     =
{'session': <Session 'gauss_tools'>}
INTERNALERROR>
mc         = <MultiCall 0 results, 1
meths, kwargs={'session': <Session 'gauss_tools'>}>
INTERNALERROR> methods    = [<function
pytest_runtestloop at 0x1001b758>, <bound method
DSession.pytest_runtestloop of <xdist.dsession.DSession instance at
0x180b5368>>]
INTERNALERROR> self       =
<HookCaller 'pytest_runtestloop'>
INTERNALERROR>
INTERNALERROR>
/home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest-2.0.1.dev5-py2.6.egg/_pytest/core.py:401:
INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
INTERNALERROR>
INTERNALERROR> self = <MultiCall 0 results, 1 meths,
kwargs={'session': <Session 'gauss_tools'>}>
INTERNALERROR>
INTERNALERROR>     def execute(self):
INTERNALERROR>        
while self.methods:
INTERNALERROR>            
method = self.methods.pop()
INTERNALERROR>            
kwargs = self.getkwargs(method)
INTERNALERROR>
>           res =
method(**kwargs)
INTERNALERROR>
INTERNALERROR> kwargs     = {}
INTERNALERROR> method     = <bound
method DSession.pytest_runtestloop of <xdist.dsession.DSession instance at
0x180b5368>>
INTERNALERROR> self       =
<MultiCall 0 results, 1 meths, kwargs={'session': <Session
'gauss_tools'>}>
INTERNALERROR>
INTERNALERROR> 
/home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest-2.0.1.dev5-py2.6.egg/_pytest/core.py:322:
INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
INTERNALERROR>
INTERNALERROR> self = <xdist.dsession.DSession
instance at 0x180b5368>
INTERNALERROR>
INTERNALERROR>     def
pytest_runtestloop(self):
INTERNALERROR>        
numnodes = len(self.nodemanager.specs)
INTERNALERROR>        
dist = self.config.getvalue("dist")
INTERNALERROR>        
if dist == "load":
INTERNALERROR>            
self.sched = LoadScheduling(numnodes, log=self.log)
INTERNALERROR>        
elif dist == "each":
INTERNALERROR>            
self.sched = EachScheduling(numnodes, log=self.log)
INTERNALERROR>        
else:
INTERNALERROR>            
assert 0, dist
INTERNALERROR>        
self.shouldstop = False
INTERNALERROR>        
self.session_finished = False
INTERNALERROR>        
while not self.session_finished:
INTERNALERROR>
>          
self.loop_once()
INTERNALERROR>
INTERNALERROR> dist       =
'load'
INTERNALERROR> numnodes   = 2
INTERNALERROR> self       =
<xdist.dsession.DSession instance at 0x180b5368>
INTERNALERROR>
INTERNALERROR> 
/home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest_xdist-1.6.dev2-py2.6.egg/xdist/dsession.py:204:
INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
INTERNALERROR>
INTERNALERROR> self = <xdist.dsession.DSession
instance at 0x180b5368>
INTERNALERROR>
INTERNALERROR>     def
loop_once(self):
INTERNALERROR>        
""" process one callback from one of the slaves.
"""
INTERNALERROR>         while
1:
INTERNALERROR>            
try:
INTERNALERROR>                
eventcall = self.queue.get(timeout=2.0)
INTERNALERROR>                
break
INTERNALERROR>            
except queue.Empty:
INTERNALERROR>                
continue
INTERNALERROR>         callname,
kwargs = eventcall
INTERNALERROR>        
assert callname, kwargs
INTERNALERROR>        
method = "slave_" + callname
INTERNALERROR>        
call = getattr(self, method)
INTERNALERROR>        
self.log("calling method: %s(**%s)" % (method, kwargs))
INTERNALERROR> >      
call(**kwargs)
INTERNALERROR>
INTERNALERROR> call       =
<bound method DSession.slave_testreport of <xdist.dsession.DSession
instance at 0x180b5368>>
INTERNALERROR> callname   = 'testreport'
INTERNALERROR> eventcall  = ('testreport', {'node':
<SlaveController gw0>, 'rep':  {snip}

when='call' outcome='passed'>})
INTERNALERROR> kwargs     = {'node':
<SlaveController gw0>, 'rep': {snip}
when='call' outcome='passed'>}
INTERNALERROR> method     =
'slave_testreport'
INTERNALERROR> self       =
<xdist.dsession.DSession instance at 0x180b5368>
INTERNALERROR>
INTERNALERROR>
/home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest_xdist-1.6.dev2-py2.6.egg/xdist/dsession.py:222:
INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
INTERNALERROR>
INTERNALERROR> self = <xdist.dsession.DSession
instance at 0x180b5368>, node = <SlaveController gw0>
INTERNALERROR> rep = <TestReport {snip}
when='call' outcome='passed'>
INTERNALERROR>
INTERNALERROR>     def
slave_testreport(self, node, rep):
INTERNALERROR>         if
rep.when in ("setup", "call"):
INTERNALERROR>
>          
self.sched.remove_item(node, rep.nodeid)
INTERNALERROR>
INTERNALERROR> node       =
<SlaveController gw0>
INTERNALERROR>
rep        = <TestReport {snip}
when='call' outcome='passed'>
INTERNALERROR> self       =
<xdist.dsession.DSession instance at 0x180b5368>
INTERNALERROR>
INTERNALERROR>
/home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest_xdist-1.6.dev2-py2.6.egg/xdist/dsession.py:283:
INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
INTERNALERROR>
INTERNALERROR> self = <xdist.dsession.LoadScheduling
instance at 0x1930f368>, node = <SlaveController gw0>


{item removed}

INTERNALERROR>
INTERNALERROR>     def
remove_item(self, node, item):
INTERNALERROR>        
if item not in self.item2nodes:
INTERNALERROR>            
raise AssertiDN_XSS_NEUTRALIZE_onError(item, self.item2nodes)
INTERNALERROR>        
nodes = self.item2nodes[item]
INTERNALERROR>        
if node in nodes: # the node might have gone down already
INTERNALERROR>            
nodes.remove(node)
INTERNALERROR>        
#if not nodes:
INTERNALERROR>        
#    del self.item2nodes[item]
INTERNALERROR>        
pending = self.node2pending[node]
INTERNALERROR> >      
pending.remove(item)
INTERNALERROR> E      
ValueError: list.remove(x): x not in list
INTERNALERROR>
{item and pending removed}

INTERNALERROR> node       =
<SlaveController gw0>

INTERNALERROR> nodes      = []
INTERNALERROR> self       =
<xdist.dsession.LoadScheduling instance at 0x1930f368>

INTERNALERROR>


INTERNALERROR> 
/home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest_xdist-1.6.dev2-py2.6.egg/xdist/dsession.py:103:
ValueError


Regards,

Andy Fundinger

Risk Focus Inc.
424.243.6227


New York  Office: +1 917 725 6006  Fax: +1 917 591 1616

London  Office: +44 (0) 207 760 7184  Fax: +44 (0) 207 691 7165
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20101210/a68b54d7/attachment-0001.htm 

From holger at merlinux.eu  Fri Dec 10 16:44:18 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 10 Dec 2010 16:44:18 +0100
Subject: [py-dev] Internal Error in xdist remove
In-Reply-To: <10088290.959.1291990637762.JavaMail.root@ip-208-109-234-141.ip.secureserver.net>
References: <10088290.959.1291990637762.JavaMail.root@ip-208-109-234-141.ip.secureserver.net>
Message-ID: <20101210154418.GK13842@trillke.net>

Hi Andy,

Probably there is some error that his hidden behind this weird traceback.
Can't look into it at the moment.  Can you come with a repeatable example
and maybe file an issue?  In any case i am off for three weeks so don't
expect an answer from my side, maybe somebody else can help you, though.

cheers,
holger


On Fri, Dec 10, 2010 at 09:17 -0500, Andy Fundinger wrote:
> Continuing my attempted upgrade to pytest 2.0.0 I'm running into some errors with using xdist for parallel testing, this test is meant to run on two local nodes in parallel and boxed, but somehow it's trying to remove something that isn't there.  Any ideas?  The full log is below with a few bits removed because they reference my source code, if they're critical I can obscure the data rather than removing them or try to reproduce with non-project code.
> 
> 
> Andy Fundinger
> 
> 
> 
> scheduling tests via LoadScheduling
> INTERNALERROR> config = <_pytest.config.Config object
> at 0xff22a90>
> INTERNALERROR>
> INTERNALERROR>     def
> pytest_cmdline_main(config):
> INTERNALERROR>        
> """ default command line protocol for initialization, session,
> INTERNALERROR>        
> running tests and reporting. """
> INTERNALERROR>        
> session = Session(config)
> INTERNALERROR>        
> session.exitstatus = EXIT_OK
> INTERNALERROR>        
> try:
> INTERNALERROR>            
> config.pluginmanager.do_configure(config)
> INTERNALERROR>            
> config.hook.pytest_sessionstart(session=session)
> INTERNALERROR>            
> config.hook.pytest_collection(session=session)
> INTERNALERROR> >           config.hook.pytest_runtestloop(session=session)
> INTERNALERROR>
> INTERNALERROR> config     =
> <_pytest.config.Config object at 0xff22a90>
> INTERNALERROR> session    = <Session
> 'gauss_tools'>
> INTERNALERROR>
> INTERNALERROR> 
> /home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest-2.0.1.dev5-py2.6.egg/_pytest/main.py:65:
> INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> INTERNALERROR>
> INTERNALERROR> self = <HookCaller
> 'pytest_runtestloop'>
> INTERNALERROR>
> INTERNALERROR>     def __call__(self,
> **kwargs):
> INTERNALERROR>        
> methods = self.hookrelay._pm.listattr(self.name)
> INTERNALERROR> >      
> return self._docall(methods, kwargs)
> INTERNALERROR>
> INTERNALERROR> kwargs     =
> {'session': <Session 'gauss_tools'>}
> INTERNALERROR> methods    = [<function
> pytest_runtestloop at 0x1001b758>, <bound method
> DSession.pytest_runtestloop of <xdist.dsession.DSession instance at
> 0x180b5368>>]
> INTERNALERROR> self       =
> <HookCaller 'pytest_runtestloop'>
> INTERNALERROR>
> INTERNALERROR>
> /home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest-2.0.1.dev5-py2.6.egg/_pytest/core.py:390:
> INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> INTERNALERROR>
> INTERNALERROR> self = <HookCaller
> 'pytest_runtestloop'>
> INTERNALERROR> methods = [<function pytest_runtestloop
> at 0x1001b758>, <bound method DSession.pytest_runtestloop of
> <xdist.dsession.DSession instance at 0x180b5368>>]
> INTERNALERROR> kwargs = {'session': <Session
> 'gauss_tools'>}
> INTERNALERROR>
> INTERNALERROR>     def _docall(self,
> methods, kwargs):
> INTERNALERROR>        
> self.trace(self.name, kwargs)
> INTERNALERROR>        
> self.trace.root.indent += 1
> INTERNALERROR>        
> mc = MultiCall(methods, kwargs, firstresult=self.firstresult)
> INTERNALERROR>        
> try:
> INTERNALERROR>
> >           res =
> mc.execute()
> INTERNALERROR>
> INTERNALERROR> kwargs     =
> {'session': <Session 'gauss_tools'>}
> INTERNALERROR>
> mc         = <MultiCall 0 results, 1
> meths, kwargs={'session': <Session 'gauss_tools'>}>
> INTERNALERROR> methods    = [<function
> pytest_runtestloop at 0x1001b758>, <bound method
> DSession.pytest_runtestloop of <xdist.dsession.DSession instance at
> 0x180b5368>>]
> INTERNALERROR> self       =
> <HookCaller 'pytest_runtestloop'>
> INTERNALERROR>
> INTERNALERROR>
> /home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest-2.0.1.dev5-py2.6.egg/_pytest/core.py:401:
> INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> INTERNALERROR>
> INTERNALERROR> self = <MultiCall 0 results, 1 meths,
> kwargs={'session': <Session 'gauss_tools'>}>
> INTERNALERROR>
> INTERNALERROR>     def execute(self):
> INTERNALERROR>        
> while self.methods:
> INTERNALERROR>            
> method = self.methods.pop()
> INTERNALERROR>            
> kwargs = self.getkwargs(method)
> INTERNALERROR>
> >           res =
> method(**kwargs)
> INTERNALERROR>
> INTERNALERROR> kwargs     = {}
> INTERNALERROR> method     = <bound
> method DSession.pytest_runtestloop of <xdist.dsession.DSession instance at
> 0x180b5368>>
> INTERNALERROR> self       =
> <MultiCall 0 results, 1 meths, kwargs={'session': <Session
> 'gauss_tools'>}>
> INTERNALERROR>
> INTERNALERROR> 
> /home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest-2.0.1.dev5-py2.6.egg/_pytest/core.py:322:
> INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> INTERNALERROR>
> INTERNALERROR> self = <xdist.dsession.DSession
> instance at 0x180b5368>
> INTERNALERROR>
> INTERNALERROR>     def
> pytest_runtestloop(self):
> INTERNALERROR>        
> numnodes = len(self.nodemanager.specs)
> INTERNALERROR>        
> dist = self.config.getvalue("dist")
> INTERNALERROR>        
> if dist == "load":
> INTERNALERROR>            
> self.sched = LoadScheduling(numnodes, log=self.log)
> INTERNALERROR>        
> elif dist == "each":
> INTERNALERROR>            
> self.sched = EachScheduling(numnodes, log=self.log)
> INTERNALERROR>        
> else:
> INTERNALERROR>            
> assert 0, dist
> INTERNALERROR>        
> self.shouldstop = False
> INTERNALERROR>        
> self.session_finished = False
> INTERNALERROR>        
> while not self.session_finished:
> INTERNALERROR>
> >          
> self.loop_once()
> INTERNALERROR>
> INTERNALERROR> dist       =
> 'load'
> INTERNALERROR> numnodes   = 2
> INTERNALERROR> self       =
> <xdist.dsession.DSession instance at 0x180b5368>
> INTERNALERROR>
> INTERNALERROR> 
> /home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest_xdist-1.6.dev2-py2.6.egg/xdist/dsession.py:204:
> INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> INTERNALERROR>
> INTERNALERROR> self = <xdist.dsession.DSession
> instance at 0x180b5368>
> INTERNALERROR>
> INTERNALERROR>     def
> loop_once(self):
> INTERNALERROR>        
> """ process one callback from one of the slaves.
> """
> INTERNALERROR>         while
> 1:
> INTERNALERROR>            
> try:
> INTERNALERROR>                
> eventcall = self.queue.get(timeout=2.0)
> INTERNALERROR>                
> break
> INTERNALERROR>            
> except queue.Empty:
> INTERNALERROR>                
> continue
> INTERNALERROR>         callname,
> kwargs = eventcall
> INTERNALERROR>        
> assert callname, kwargs
> INTERNALERROR>        
> method = "slave_" + callname
> INTERNALERROR>        
> call = getattr(self, method)
> INTERNALERROR>        
> self.log("calling method: %s(**%s)" % (method, kwargs))
> INTERNALERROR> >      
> call(**kwargs)
> INTERNALERROR>
> INTERNALERROR> call       =
> <bound method DSession.slave_testreport of <xdist.dsession.DSession
> instance at 0x180b5368>>
> INTERNALERROR> callname   = 'testreport'
> INTERNALERROR> eventcall  = ('testreport', {'node':
> <SlaveController gw0>, 'rep':  {snip}
> 
> when='call' outcome='passed'>})
> INTERNALERROR> kwargs     = {'node':
> <SlaveController gw0>, 'rep': {snip}
> when='call' outcome='passed'>}
> INTERNALERROR> method     =
> 'slave_testreport'
> INTERNALERROR> self       =
> <xdist.dsession.DSession instance at 0x180b5368>
> INTERNALERROR>
> INTERNALERROR>
> /home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest_xdist-1.6.dev2-py2.6.egg/xdist/dsession.py:222:
> INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> INTERNALERROR>
> INTERNALERROR> self = <xdist.dsession.DSession
> instance at 0x180b5368>, node = <SlaveController gw0>
> INTERNALERROR> rep = <TestReport {snip}
> when='call' outcome='passed'>
> INTERNALERROR>
> INTERNALERROR>     def
> slave_testreport(self, node, rep):
> INTERNALERROR>         if
> rep.when in ("setup", "call"):
> INTERNALERROR>
> >          
> self.sched.remove_item(node, rep.nodeid)
> INTERNALERROR>
> INTERNALERROR> node       =
> <SlaveController gw0>
> INTERNALERROR>
> rep        = <TestReport {snip}
> when='call' outcome='passed'>
> INTERNALERROR> self       =
> <xdist.dsession.DSession instance at 0x180b5368>
> INTERNALERROR>
> INTERNALERROR>
> /home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest_xdist-1.6.dev2-py2.6.egg/xdist/dsession.py:283:
> INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> INTERNALERROR>
> INTERNALERROR> self = <xdist.dsession.LoadScheduling
> instance at 0x1930f368>, node = <SlaveController gw0>
> 
> 
> {item removed}
> 
> INTERNALERROR>
> INTERNALERROR>     def
> remove_item(self, node, item):
> INTERNALERROR>        
> if item not in self.item2nodes:
> INTERNALERROR>            
> raise AssertiDN_XSS_NEUTRALIZE_onError(item, self.item2nodes)
> INTERNALERROR>        
> nodes = self.item2nodes[item]
> INTERNALERROR>        
> if node in nodes: # the node might have gone down already
> INTERNALERROR>            
> nodes.remove(node)
> INTERNALERROR>        
> #if not nodes:
> INTERNALERROR>        
> #    del self.item2nodes[item]
> INTERNALERROR>        
> pending = self.node2pending[node]
> INTERNALERROR> >      
> pending.remove(item)
> INTERNALERROR> E      
> ValueError: list.remove(x): x not in list
> INTERNALERROR>
> {item and pending removed}
> 
> INTERNALERROR> node       =
> <SlaveController gw0>
> 
> INTERNALERROR> nodes      = []
> INTERNALERROR> self       =
> <xdist.dsession.LoadScheduling instance at 0x1930f368>
> 
> INTERNALERROR>
> 
> 
> INTERNALERROR> 
> /home/andy/trunk/ext_linux64/python264/lib/python2.6/site-packages/pytest_xdist-1.6.dev2-py2.6.egg/xdist/dsession.py:103:
> ValueError
> 
> 
> Regards,
> 
> Andy Fundinger
> 
> Risk Focus Inc.
> 424.243.6227
> 
> 
> New York  Office: +1 917 725 6006  Fax: +1 917 591 1616
> 
> London  Office: +44 (0) 207 760 7184  Fax: +44 (0) 207 691 7165
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev


-- 

From hsoft at hardcoded.net  Sat Dec 18 15:51:26 2010
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Sat, 18 Dec 2010 15:51:26 +0100
Subject: [py-dev] Advanced monkeypatching?
Message-ID: <4C5E2E4C-15CF-45B7-80B1-3F0363D82E66@hardcoded.net>

Hi there,

Monkeypatching is great and all, but some type of patching is a little bit more complex to do, such as patching the system time and patching os.stat for specific filenames. I have my own "homebrewed" solution for this, but I was wondering if such solution had their place in the monkeypatch module of pytest itself. Does it? Or should a "pytest-monkeypatch++" package be created?

The "homebrewed" code I'm talking about is at https://bitbucket.org/hsoft/hsutil/src/43014954c6a8/hsutil/testutil.py#cl-83 ( patch_osstat() and patch_today() ).
--
Virgil Dupras


From flub at devork.be  Sun Dec 19 15:38:01 2010
From: flub at devork.be (Floris Bruynooghe)
Date: Sun, 19 Dec 2010 14:38:01 +0000
Subject: [py-dev] Advanced monkeypatching?
In-Reply-To: <4C5E2E4C-15CF-45B7-80B1-3F0363D82E66@hardcoded.net>
References: <4C5E2E4C-15CF-45B7-80B1-3F0363D82E66@hardcoded.net>
Message-ID: <AANLkTikhs0hfzY71bBdZSU0Y=p4aimE9wVGm0Lfvi8L=@mail.gmail.com>

Hello

On 18 December 2010 14:51, Virgil Dupras <hsoft at hardcoded.net> wrote:
> Hi there,
>
> Monkeypatching is great and all, but some type of patching is a little bit more complex to do, such as patching the system time and patching os.stat for specific filenames. I have my own "homebrewed" solution for this, but I was wondering if such solution had their place in the monkeypatch module of pytest itself. Does it? Or should a "pytest-monkeypatch++" package be created?
>
> The "homebrewed" code I'm talking about is at https://bitbucket.org/hsoft/hsutil/src/43014954c6a8/hsutil/testutil.py#cl-83 ( patch_osstat() and patch_today() ).

Looking at the patch_osstat() it seems to me that it just fakes
os.stat() for one specific path but uses the original in place
otherwise.  This sounds like it could be just a specialised object
used to patch with.  I can imagine the monkeypatch plugin to provide a
funcarg which provides this functionality, e.g.:

def test_foo(monkeypatch, monkey_osstat):
    monkeypatch.setattr(monkey_ossstat('/tmp/some_file'))
    ...

Though probably with better names ;-).

I'm not sure I understand the use case for patch_today() so won't
comment on that part.

Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From hsoft at hardcoded.net  Mon Dec 20 09:22:27 2010
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Mon, 20 Dec 2010 09:22:27 +0100
Subject: [py-dev] Advanced monkeypatching?
In-Reply-To: <AANLkTikhs0hfzY71bBdZSU0Y=p4aimE9wVGm0Lfvi8L=@mail.gmail.com>
References: <4C5E2E4C-15CF-45B7-80B1-3F0363D82E66@hardcoded.net>
	<AANLkTikhs0hfzY71bBdZSU0Y=p4aimE9wVGm0Lfvi8L=@mail.gmail.com>
Message-ID: <B7B86EF7-9AEE-44AA-B311-FCDD7D675746@hardcoded.net>

On 2010-12-19, at 3:38 PM, Floris Bruynooghe wrote:

> Hello
> 
> On 18 December 2010 14:51, Virgil Dupras <hsoft at hardcoded.net> wrote:
>> Hi there,
>> 
>> Monkeypatching is great and all, but some type of patching is a little bit more complex to do, such as patching the system time and patching os.stat for specific filenames. I have my own "homebrewed" solution for this, but I was wondering if such solution had their place in the monkeypatch module of pytest itself. Does it? Or should a "pytest-monkeypatch++" package be created?
>> 
>> The "homebrewed" code I'm talking about is at https://bitbucket.org/hsoft/hsutil/src/43014954c6a8/hsutil/testutil.py#cl-83 ( patch_osstat() and patch_today() ).
> 
> Looking at the patch_osstat() it seems to me that it just fakes
> os.stat() for one specific path but uses the original in place
> otherwise.  This sounds like it could be just a specialised object
> used to patch with.  I can imagine the monkeypatch plugin to provide a
> funcarg which provides this functionality, e.g.:
> 
> def test_foo(monkeypatch, monkey_osstat):
>    monkeypatch.setattr(monkey_ossstat('/tmp/some_file'))
>    ...
> 
> Though probably with better names ;-).
> 
> I'm not sure I understand the use case for patch_today() so won't
> comment on that part.
> 
> Regards
> Floris
> 
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org

This would kind of work, but it would become complicated to patch os.stat() for two or more files, wouldn't it?

As for patch_today(), I created it because when you want to patch the date for a test, you can't just patch datetime because there might be a function somewhere using time.time(), so you'll have inconsistent date patching. However, to patch time.time() to a datetime of your choice, you have to do some arithmetics, hence the patch_today() helper.

My question is: Does such helpers have their place in the official pytest package or should it be an external plugin?

Regards,
Virgil Dupras

From Ronny.Pfannschmidt at gmx.de  Mon Dec 20 10:41:19 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Mon, 20 Dec 2010 10:41:19 +0100
Subject: [py-dev] Advanced monkeypatching?
In-Reply-To: <B7B86EF7-9AEE-44AA-B311-FCDD7D675746@hardcoded.net>
References: <4C5E2E4C-15CF-45B7-80B1-3F0363D82E66@hardcoded.net>
	<AANLkTikhs0hfzY71bBdZSU0Y=p4aimE9wVGm0Lfvi8L=@mail.gmail.com>
	<B7B86EF7-9AEE-44AA-B311-FCDD7D675746@hardcoded.net>
Message-ID: <1292838079.8085.2.camel@Klappe2>

On Mon, 2010-12-20 at 09:22 +0100, Virgil Dupras wrote:
> On 2010-12-19, at 3:38 PM, Floris Bruynooghe wrote:
> 
> > Hello
> > 
> > On 18 December 2010 14:51, Virgil Dupras <hsoft at hardcoded.net> wrote:
> >> Hi there,
> >> 
> >> Monkeypatching is great and all, but some type of patching is a little bit more complex to do, such as patching the system time and patching os.stat for specific filenames. I have my own "homebrewed" solution for this, but I was wondering if such solution had their place in the monkeypatch module of pytest itself. Does it? Or should a "pytest-monkeypatch++" package be created?
> >> 
> >> The "homebrewed" code I'm talking about is at https://bitbucket.org/hsoft/hsutil/src/43014954c6a8/hsutil/testutil.py#cl-83 ( patch_osstat() and patch_today() ).
> > 
> > Looking at the patch_osstat() it seems to me that it just fakes
> > os.stat() for one specific path but uses the original in place
> > otherwise.  This sounds like it could be just a specialised object
> > used to patch with.  I can imagine the monkeypatch plugin to provide a
> > funcarg which provides this functionality, e.g.:
> > 
> > def test_foo(monkeypatch, monkey_osstat):
> >    monkeypatch.setattr(monkey_ossstat('/tmp/some_file'))
> >    ...
> > 
> > Though probably with better names ;-).
> > 
> > I'm not sure I understand the use case for patch_today() so won't
> > comment on that part.
> > 
> > Regards
> > Floris
> > 
> > 
> > -- 
> > Debian GNU/Linux -- The Power of Freedom
> > www.debian.org | www.gnu.org | www.kernel.org
> 
> This would kind of work, but it would become complicated to patch os.stat() for two or more files, wouldn't it?
there could be a monkey_stat object that controlls the set of
files/subtrees under control


> 
> As for patch_today(), I created it because when you want to patch the date for a test, you can't just patch datetime because there might be a function somewhere using time.time(), so you'll have inconsistent date patching. However, to patch time.time() to a datetime of your choice, you have to do some arithmetics, hence the patch_today() helper.
> 
> My question is: Does such helpers have their place in the official pytest package or should it be an external plugin?

a good starting place would be a external plugin to try different
approaches and stabilize a bit since py.test is supposed to be more
stable in the 2.x series.

regards Ronny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://codespeak.net/pipermail/py-dev/attachments/20101220/56edb928/attachment.pgp 

From hsoft at hardcoded.net  Mon Dec 20 10:56:33 2010
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Mon, 20 Dec 2010 10:56:33 +0100
Subject: [py-dev] Advanced monkeypatching?
In-Reply-To: <1292838079.8085.2.camel@Klappe2>
References: <4C5E2E4C-15CF-45B7-80B1-3F0363D82E66@hardcoded.net>
	<AANLkTikhs0hfzY71bBdZSU0Y=p4aimE9wVGm0Lfvi8L=@mail.gmail.com>
	<B7B86EF7-9AEE-44AA-B311-FCDD7D675746@hardcoded.net>
	<1292838079.8085.2.camel@Klappe2>
Message-ID: <9EE11035-3F4F-4F2A-BE4E-CCE2AD65C080@hardcoded.net>


On 2010-12-20, at 10:41 AM, Ronny Pfannschmidt wrote:
> On Mon, 2010-12-20 at 09:22 +0100, Virgil Dupras wrote:
>> On 2010-12-19, at 3:38 PM, Floris Bruynooghe wrote:
>>> 
>>> Looking at the patch_osstat() it seems to me that it just fakes
>>> os.stat() for one specific path but uses the original in place
>>> otherwise.  This sounds like it could be just a specialised object
>>> used to patch with.  I can imagine the monkeypatch plugin to provide a
>>> funcarg which provides this functionality, e.g.:
>>> 
>>> def test_foo(monkeypatch, monkey_osstat):
>>>   monkeypatch.setattr(monkey_ossstat('/tmp/some_file'))
>>>   ...
>>> 
>> 
>> This would kind of work, but it would become complicated to patch os.stat() for two or more files, wouldn't it?
> there could be a monkey_stat object that controlls the set of
> files/subtrees under control
> 

Yes, of course, but keeping the proposed API would make it unintuitive for multiple files. Example:

monkeypatch.setattr(os, 'stat', monkey_osstat('some_file'))
monkeypatch.setattr(os, 'stat', monkey_osstat('some_other_file'))

We're not sure what happens there, as os.stat is patched twice. Are we overwriting our old monkeypatch, or is there some magic caching inside monkey_osstat() making it work for both files? That's the kind of question the developer will wonder about.

From flub at devork.be  Mon Dec 20 14:47:59 2010
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 20 Dec 2010 13:47:59 +0000
Subject: [py-dev] Advanced monkeypatching?
In-Reply-To: <9EE11035-3F4F-4F2A-BE4E-CCE2AD65C080@hardcoded.net>
References: <4C5E2E4C-15CF-45B7-80B1-3F0363D82E66@hardcoded.net>
	<AANLkTikhs0hfzY71bBdZSU0Y=p4aimE9wVGm0Lfvi8L=@mail.gmail.com>
	<B7B86EF7-9AEE-44AA-B311-FCDD7D675746@hardcoded.net>
	<1292838079.8085.2.camel@Klappe2>
	<9EE11035-3F4F-4F2A-BE4E-CCE2AD65C080@hardcoded.net>
Message-ID: <AANLkTinkcr_BB=jr-SMRf73vLxWP9BJ5NH-C4ni_8jTi@mail.gmail.com>

On 20 December 2010 09:56, Virgil Dupras <hsoft at hardcoded.net> wrote:
>
> On 2010-12-20, at 10:41 AM, Ronny Pfannschmidt wrote:
>> On Mon, 2010-12-20 at 09:22 +0100, Virgil Dupras wrote:
>>> On 2010-12-19, at 3:38 PM, Floris Bruynooghe wrote:
>>>>
>>>> Looking at the patch_osstat() it seems to me that it just fakes
>>>> os.stat() for one specific path but uses the original in place
>>>> otherwise. ?This sounds like it could be just a specialised object
>>>> used to patch with. ?I can imagine the monkeypatch plugin to provide a
>>>> funcarg which provides this functionality, e.g.:
>>>>
>>>> def test_foo(monkeypatch, monkey_osstat):
>>>> ? monkeypatch.setattr(monkey_ossstat('/tmp/some_file'))
>>>> ? ...
>>>>
>>>
>>> This would kind of work, but it would become complicated to patch os.stat() for two or more files, wouldn't it?
>> there could be a monkey_stat object that controlls the set of
>> files/subtrees under control
>>
>
> Yes, of course, but keeping the proposed API would make it unintuitive for multiple files. Example:
>
> monkeypatch.setattr(os, 'stat', monkey_osstat('some_file'))
> monkeypatch.setattr(os, 'stat', monkey_osstat('some_other_file'))
>
> We're not sure what happens there, as os.stat is patched twice. Are we overwriting our old monkeypatch, or is there some magic caching inside monkey_osstat() making it work for both files? That's the kind of question the developer will wonder about.

I was thinking of something slightly different when I said this:

def test_foo(monkeypatch, monkey_osstat):
    stat = monkey_ossstat('file1', 'file2')
    stat.add_file('file3')
    monkeypatch.setattr(os, 'stat', stat)
    stat.add_file('file4', st_size=123)

That makes it very clear what happens (at least to me).

But as Ronny said it's probably best to try out the various approaches
in an external plugin to get past the bikeshedding.  If that results
in a stable api which is getting used it could be merged with the
core.  This is what is happening to the capturelog plugin too I think.

As for the patch_time() I've never needed it but I understand now why
you want it.  Doing this via a funcarg which you then use in one of
the normal monkeypatch methods will probably be very cumbersome so a
funcarg that does the patching directly is probably the way to go
(which could eventually become something like
"monkeypatch.patch_time(...)" I guess)

Regards
Floris

PS: I speak with no authority to the development of py.test, I'm just
another user.


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From Ronny.Pfannschmidt at gmx.de  Tue Dec 21 10:54:19 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Tue, 21 Dec 2010 10:54:19 +0100
Subject: [py-dev] Advanced monkeypatching?
In-Reply-To: <AANLkTinkcr_BB=jr-SMRf73vLxWP9BJ5NH-C4ni_8jTi@mail.gmail.com>
References: <4C5E2E4C-15CF-45B7-80B1-3F0363D82E66@hardcoded.net>
	<AANLkTikhs0hfzY71bBdZSU0Y=p4aimE9wVGm0Lfvi8L=@mail.gmail.com>
	<B7B86EF7-9AEE-44AA-B311-FCDD7D675746@hardcoded.net>
	<1292838079.8085.2.camel@Klappe2>
	<9EE11035-3F4F-4F2A-BE4E-CCE2AD65C080@hardcoded.net>
	<AANLkTinkcr_BB=jr-SMRf73vLxWP9BJ5NH-C4ni_8jTi@mail.gmail.com>
Message-ID: <1292925260.8085.6.camel@Klappe2>

On Mon, 2010-12-20 at 13:47 +0000, Floris Bruynooghe wrote:
> On 20 December 2010 09:56, Virgil Dupras <hsoft at hardcoded.net> wrote:
> >
> > On 2010-12-20, at 10:41 AM, Ronny Pfannschmidt wrote:
> >> On Mon, 2010-12-20 at 09:22 +0100, Virgil Dupras wrote:
> >>> On 2010-12-19, at 3:38 PM, Floris Bruynooghe wrote:
> >>>>
> >>>> Looking at the patch_osstat() it seems to me that it just fakes
> >>>> os.stat() for one specific path but uses the original in place
> >>>> otherwise.  This sounds like it could be just a specialised object
> >>>> used to patch with.  I can imagine the monkeypatch plugin to provide a
> >>>> funcarg which provides this functionality, e.g.:
> >>>>
> >>>> def test_foo(monkeypatch, monkey_osstat):
> >>>>   monkeypatch.setattr(monkey_ossstat('/tmp/some_file'))
> >>>>   ...
> >>>>
> >>>
> >>> This would kind of work, but it would become complicated to patch os.stat() for two or more files, wouldn't it?
> >> there could be a monkey_stat object that controlls the set of
> >> files/subtrees under control
> >>
> >
> > Yes, of course, but keeping the proposed API would make it unintuitive for multiple files. Example:
> >
> > monkeypatch.setattr(os, 'stat', monkey_osstat('some_file'))
> > monkeypatch.setattr(os, 'stat', monkey_osstat('some_other_file'))
> >
> > We're not sure what happens there, as os.stat is patched twice. Are we overwriting our old monkeypatch, or is there some magic caching inside monkey_osstat() making it work for both files? That's the kind of question the developer will wonder about.
> 
> I was thinking of something slightly different when I said this:
> 
> def test_foo(monkeypatch, monkey_osstat):
>     stat = monkey_ossstat('file1', 'file2')
>     stat.add_file('file3')
>     monkeypatch.setattr(os, 'stat', stat)
>     stat.add_file('file4', st_size=123)

i was thinking more along the lines of::

    def test_foo(osstat_patch):
        stat.add_file(...) #setup single files
        stat.add_callback(root, somefunction) # hand off a whole tree

i suppose better function names are possible
also im wondering if this should integrate with py.path more deeply
(having a virtual view on the whole fs seems neat)

> 
> That makes it very clear what happens (at least to me).
> 
> But as Ronny said it's probably best to try out the various approaches
> in an external plugin to get past the bikeshedding.  If that results
> in a stable api which is getting used it could be merged with the
> core.  This is what is happening to the capturelog plugin too I think.
> 
> As for the patch_time() I've never needed it but I understand now why
> you want it.  Doing this via a funcarg which you then use in one of
> the normal monkeypatch methods will probably be very cumbersome so a
> funcarg that does the patching directly is probably the way to go
> (which could eventually become something like
> "monkeypatch.patch_time(...)" I guess)
> 
> Regards
> Floris
> 
> PS: I speak with no authority to the development of py.test, I'm just
> another user.
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://codespeak.net/pipermail/py-dev/attachments/20101221/295ac000/attachment.pgp 

From flub at devork.be  Tue Dec 21 11:45:46 2010
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 21 Dec 2010 10:45:46 +0000
Subject: [py-dev] Advanced monkeypatching?
In-Reply-To: <1292925260.8085.6.camel@Klappe2>
References: <4C5E2E4C-15CF-45B7-80B1-3F0363D82E66@hardcoded.net>
	<AANLkTikhs0hfzY71bBdZSU0Y=p4aimE9wVGm0Lfvi8L=@mail.gmail.com>
	<B7B86EF7-9AEE-44AA-B311-FCDD7D675746@hardcoded.net>
	<1292838079.8085.2.camel@Klappe2>
	<9EE11035-3F4F-4F2A-BE4E-CCE2AD65C080@hardcoded.net>
	<AANLkTinkcr_BB=jr-SMRf73vLxWP9BJ5NH-C4ni_8jTi@mail.gmail.com>
	<1292925260.8085.6.camel@Klappe2>
Message-ID: <AANLkTin056+F2YacvTMfqozTakmtTp5b5oOY5vcLec8h@mail.gmail.com>

On 21 December 2010 09:54, Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de> wrote:
> On Mon, 2010-12-20 at 13:47 +0000, Floris Bruynooghe wrote:
>> On 20 December 2010 09:56, Virgil Dupras <hsoft at hardcoded.net> wrote:
>> >
>> > On 2010-12-20, at 10:41 AM, Ronny Pfannschmidt wrote:
>> >> On Mon, 2010-12-20 at 09:22 +0100, Virgil Dupras wrote:
>> >>> On 2010-12-19, at 3:38 PM, Floris Bruynooghe wrote:
>> >>>>
>> >>>> Looking at the patch_osstat() it seems to me that it just fakes
>> >>>> os.stat() for one specific path but uses the original in place
>> >>>> otherwise. ?This sounds like it could be just a specialised object
>> >>>> used to patch with. ?I can imagine the monkeypatch plugin to provide a
>> >>>> funcarg which provides this functionality, e.g.:
>> >>>>
>> >>>> def test_foo(monkeypatch, monkey_osstat):
>> >>>> ? monkeypatch.setattr(monkey_ossstat('/tmp/some_file'))
>> >>>> ? ...
>> >>>>
>> >>>
>> >>> This would kind of work, but it would become complicated to patch os.stat() for two or more files, wouldn't it?
>> >> there could be a monkey_stat object that controlls the set of
>> >> files/subtrees under control
>> >>
>> >
>> > Yes, of course, but keeping the proposed API would make it unintuitive for multiple files. Example:
>> >
>> > monkeypatch.setattr(os, 'stat', monkey_osstat('some_file'))
>> > monkeypatch.setattr(os, 'stat', monkey_osstat('some_other_file'))
>> >
>> > We're not sure what happens there, as os.stat is patched twice. Are we overwriting our old monkeypatch, or is there some magic caching inside monkey_osstat() making it work for both files? That's the kind of question the developer will wonder about.
>>
>> I was thinking of something slightly different when I said this:
>>
>> def test_foo(monkeypatch, monkey_osstat):
>> ? ? stat = monkey_ossstat('file1', 'file2')
>> ? ? stat.add_file('file3')
>> ? ? monkeypatch.setattr(os, 'stat', stat)
>> ? ? stat.add_file('file4', st_size=123)
>
> i was thinking more along the lines of::
>
> ? ?def test_foo(osstat_patch):
> ? ? ? ?stat.add_file(...) #setup single files
> ? ? ? ?stat.add_callback(root, somefunction) # hand off a whole tree
>
> i suppose better function names are possible
> also im wondering if this should integrate with py.path more deeply
> (having a virtual view on the whole fs seems neat)

That is a nice idea, I have at least one test where I create a simple
directory structure using (the old) py.test.ensuretemp() to test if
some sorting on different os.stat() fields works in a function.  This
is an annoying case since I need to do time.sleep() in between
creating the files as some platforms don't have a high enough
resolution on file timestamps.  So being able to "set" stat attributes
on py.path items would certainly be an interesting area to explore.


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From ralf at brainbot.com  Mon Dec 27 20:12:33 2010
From: ralf at brainbot.com (Ralf Schmitt)
Date: Mon, 27 Dec 2010 20:12:33 +0100
Subject: [py-dev] use of md5 checksum in config.py/getconftestmodules looks
	fishy
Message-ID: <87lj3b6ndq.fsf@muni.brainbot.com>


_pytest/config.py contains the following code:

,----
| ...
| conftestpath = path.join("conftest.py")
| if conftestpath.check(file=1):
|     key = conftestpath.computehash()
|     # XXX logging about conftest loading
|     if key not in self._md5cache:
|         clist.append(self.importconftest(conftestpath))
|         self._md5cache[key] = conftestpath
|     else:
|         # use some kind of logging
|         print ("WARN: not loading %s" % conftestpath)
`----

If I put multiple conftest.py files with the same content into different
subdirecties py.test will only read one of them. I try to make py.test
ignore multiple subdirectories by putting the same conftest.py file into
those subdirectories. py.test currently only ignores one of those.


Regards
-- Ralf