0.11 status update

[jason pellerin]

The pycon sprint work from the bitbucket repos has been committed to
svn trunk. Thanks again to all of the sprinters.

There are still some docs to write, review and update, and any changes
coming out of Kumar's review of the new collect only/--failed
features, but we're almost there.

JP

[Kumar McMillan]

cooool. btw, pull request for some minor changes to the attribute plugin :

http://bitbucket.org/kumar303/nose-pycon/

* I wrote a better intro to the Attribute plugin's documentation
* I added an @attr decorator to make setting attributes easier (I
actually have been copying this from project to project). I added
examples of this in the docs. Is the name @attr ok?

>
> JP
>
> >
>

[jason pellerin]

Cool. I'll pull the changesets today if I can. (Though now that we're
back on google code, due to the way we got back there, I can't do
direct pulls, so it would be easier to get a patch to apply.)

There's not much remaining open for 0.11. One question is whether to
try to include James Casbon's performance testing plugin, since it's
implemented and ready for review. I'm -0 on that just because I'm
impatient to get the release out, but I'm willing to be convinced that
it should go in.

Thoughts?

JP

[Kumar McMillan]

On Thu, Apr 23, 2009 at 9:07 AM, jason pellerin <jpel...@gmail.com> wrote:
>
> Cool. I'll pull the changesets today if I can. (Though now that we're
> back on google code, due to the way we got back there, I can't do
> direct pulls, so it would be easier to get a patch to apply.)

with some ninja help from Augie, all I needed was to add this to my .hg/hgrc :

default = svn+https://python-nose.googlecode.com/svn

and I was able to run hg pull and get all svn changes. Then I had to
checkout tip and run hg transplant 678 (which was the start of my two
commits). That put them on the tip and I ran hg svn push default and
now they are in subversion trunk.

>
> There's not much remaining open for 0.11. One question is whether to
> try to include James Casbon's performance testing plugin, since it's
> implemented and ready for review. I'm -0 on that just because I'm
> impatient to get the release out, but I'm willing to be convinced that
> it should go in.
>
> Thoughts?

I took a quick look and it looked good, tests were all there. I
wasn't able to try it out though.

[jason pellerin]

On Thu, Apr 23, 2009 at 10:41 AM, Kumar McMillan
<kumar.m...@gmail.com> wrote:
>
> On Thu, Apr 23, 2009 at 9:07 AM, jason pellerin <jpel...@gmail.com> wrote:
>>
>> Cool. I'll pull the changesets today if I can. (Though now that we're
>> back on google code, due to the way we got back there, I can't do
>> direct pulls, so it would be easier to get a patch to apply.)
>
> with some ninja help from Augie, all I needed was to add this to my .hg/hgrc :

Nice. But in seeing your commits fly by I noticed that the @attr test
is not 2.3 compatible. ;)

Otherwise looks good. Thanks!

JP

[James Casbon]

2009/4/23 Kumar McMillan <kumar.m...@gmail.com>:

>
> On Thu, Apr 23, 2009 at 9:07 AM, jason pellerin <jpel...@gmail.com> wrote:
>> There's not much remaining open for 0.11. One question is whether to
>> try to include James Casbon's performance testing plugin, since it's
>> implemented and ready for review. I'm -0 on that just because I'm
>> impatient to get the release out, but I'm willing to be convinced that
>> it should go in.
>>
>> Thoughts?
>
> I took a quick look and it looked good, tests were all there.  I
> wasn't able to try it out though.

I think the performance testing needs a bit more thought. Especially regards:
* interactions with other plugins (i.e. multiprocessing or whatever
it's called).
* whether the approach is even the right way to do it (reyielding tests)
* it doesn't address the bug reporters use case at the moment.

How impatient are you? I don't suppose that was very convincing.

[James Casbon]

2009/4/18 jason pellerin <jpel...@gmail.com>:

>
> The pycon sprint work from the bitbucket repos has been committed to
> svn trunk. Thanks again to all of the sprinters.
>

What's the status with this? Where should code be going, into svn or mercurial?

It's a bit confusing for those of us outside the sprint.

[James Casbon]

2009/4/18 jason pellerin <jpel...@gmail.com>:

> There are still some docs to write, review and update, and any changes
> coming out of Kumar's review of the new collect only/--failed
> features, but we're almost there.

I just remembered my personal gripe about the docs: how to set up the
activation of a plugin.

Some examples have a class level name attribute that seems to get
picked up. Some let the base class do it. Others activate themselves
based on run time options. Since this is the first obstacle a
plugin author comes to, I think the activation process should have
something specific written about it. Especially waht you should be
doing.

thanks,
James

[Kumar McMillan]

On Thu, Apr 23, 2009 at 9:42 AM, jason pellerin <jpel...@gmail.com> wrote:
>
> Nice. But in seeing your commits fly by I noticed that the @attr test
> is not 2.3 compatible. ;)

d'oh. Fixed and committed to svn trunk. I gave up on building python
2.3 and just installed it with macports (why didn't I think of that
sooner?). The tests all pass with my fixes in 2.3 except for the
doctests. I assume that is OK because the multiprocess plugin
doctests also fail in 2.3?

[Kumar McMillan]

On Thu, Apr 23, 2009 at 10:26 AM, James Casbon <cas...@gmail.com> wrote:
>
> 2009/4/18 jason pellerin <jpel...@gmail.com>:
>
>> There are still some docs to write, review and update, and any changes
>> coming out of Kumar's review of the new collect only/--failed
>> features, but we're almost there.
>
> I just remembered my personal gripe about the docs:  how to set up the
> activation of a plugin.

yes, that was a gripe I had too. The new docs are better organized
now so it's easier to find the part about registering a plugin.
However, I didn't see a section about registering without setuptools.
I committed a change to the docs for this (the example code worked
when I tried it). JP, does this look right?

Registering a plugin without setuptools
=======================================

It is currently possible to register a plugin programmatically by
creating a custom nose runner like this :

.. code-block:: python

import nose
from yourplugin import YourPlugin

if __name__ == '__main__':
nose.main(addplugins=[YourPlugin()])

>
> Some examples have a class level name attribute that seems to get
> picked up.  Some let the base class do it.  Others activate themselves
> based on run time options.    Since this is the first obstacle a
> plugin author comes to, I think the activation process should have
> something specific written about it.  Especially waht you should be
> doing.

hmm, yeah, this might need further explanation. but I think the new
plugin writing docs are enough of an improvement to release as-is.

>
> thanks,
> James
>
> >
>

[jason pellerin]

On Thu, Apr 23, 2009 at 11:59 AM, Kumar McMillan
<kumar.m...@gmail.com> wrote:
>
> On Thu, Apr 23, 2009 at 10:26 AM, James Casbon <cas...@gmail.com> wrote:
>>
>> 2009/4/18 jason pellerin <jpel...@gmail.com>:
>>
>>> There are still some docs to write, review and update, and any changes
>>> coming out of Kumar's review of the new collect only/--failed
>>> features, but we're almost there.
>>
>> I just remembered my personal gripe about the docs:  how to set up the
>> activation of a plugin.
>
> yes, that was a gripe I had too.  The new docs are better organized
> now so it's easier to find the part about registering a plugin.
> However, I didn't see a section about registering without setuptools.
> I committed a change to the docs for this (the example code worked
> when I tried it).  JP, does this look right?

Yes, that looks good.

JP

[jason pellerin]

Nope, the multiprocess failing is an error. In general if a test can't
run under version X it should skip. For doctest files, you can use the
new doctest file fixture stuff for that. I'll check out the
multiprocess one, I didn't know it was failing under 2.3.

JP

[jason pellerin]

I don't actually see the multiprocess doctest file failing on 2.3 --
can you send me what you're seeing there?

JP

[Kumar McMillan]

On Thu, Apr 23, 2009 at 2:12 PM, jason pellerin <jpel...@gmail.com> wrote:
>
> I don't actually see the multiprocess doctest file failing on 2.3 --
> can you send me what you're seeing there?

If I run python2.3 selftest.py I see

======================================================================
FAIL: Doctest: test_withid_failures.rst
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/kumar/src/nose-pycon/nose/ext/dtcompat.py", line 1977, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test_withid_failures.rst
File "/Users/kumar/src/nose-pycon/functional_tests/test_withid_failures.rst",
line 0

----------------------------------------------------------------------
File "/Users/kumar/src/nose-pycon/functional_tests/test_withid_failures.rst",
line 35, in test_withid_failures.rst
Failed example:
run(argv=argv, plugins=[TestId()])
Expected:
#1 Failure: ImportError (No module named apackagethatdoesntexist) ... ERROR
<BLANKLINE>
======================================================================
ERROR: Failure: ImportError (No module named apackagethatdoesntexist)
----------------------------------------------------------------------
Traceback (most recent call last):
...
ImportError: No module named apackagethatdoesntexist
<BLANKLINE>
----------------------------------------------------------------------
Ran 1 test in ...s
<BLANKLINE>
FAILED (errors=1)
Got:
----------------------------------------------------------------------
Ran 0 tests in ...s
<BLANKLINE>
OK

[jason pellerin]

On Thu, Apr 23, 2009 at 3:50 PM, Kumar McMillan
<kumar.m...@gmail.com> wrote:
>
> On Thu, Apr 23, 2009 at 2:12 PM, jason pellerin <jpel...@gmail.com> wrote:
>>
>> I don't actually see the multiprocess doctest file failing on 2.3 --
>> can you send me what you're seeing there?
>
> If I run python2.3 selftest.py I see
>
>
> ======================================================================
> FAIL: Doctest: test_withid_failures.rst

Ah, that is not the multprocess doctest at all. :)

That and the docstring of attrib are fixed on trunk.

JP

[Kumar McMillan]

On Thu, Apr 23, 2009 at 5:29 PM, jason pellerin <jpel...@gmail.com> wrote:
>
> On Thu, Apr 23, 2009 at 3:50 PM, Kumar McMillan
> <kumar.m...@gmail.com> wrote:
>>
>> On Thu, Apr 23, 2009 at 2:12 PM, jason pellerin <jpel...@gmail.com> wrote:
>>>
>>> I don't actually see the multiprocess doctest file failing on 2.3 --
>>> can you send me what you're seeing there?
>>
>> If I run python2.3 selftest.py I see
>>
>>
>> ======================================================================
>> FAIL: Doctest: test_withid_failures.rst
>
> Ah, that is not the multprocess doctest at all. :)

whoa, you're right, not sure what I was thinking, heh.

>
> That and the docstring of attrib are fixed on trunk.

hmm, that's a shame that the example code gets obscured for 2.3
compatibility. As doctests they aren't really testing much more than
an import. Do you think it would make more sense to turn them into
code-blocks instead of doctests?

>
> JP
>
> >
>

[jason pellerin]

> hmm, that's a shame that the example code gets obscured for 2.3
> compatibility.  As doctests they aren't really testing much more than
> an import.  Do you think it would make more sense to turn them into
> code-blocks instead of doctests?

I was thinking of doing that too, but didn't want to muck about too
much with your examples. I agree they'd read a lot better without the
2.3 cruft, so if they're not testing anything usefully, I'd vote to
switch them.

JP