bugs, 0.11 features and new team member
jason pellerin
First up, please welcome Michał Kwiatkowski to the dev team. Seven
developers -- pretty good!
Next, there are a couple of bug reports for 0.10.0 final that I think
are important to fix soon, but which I probably won't get to this week
-- if someone wants to claim them, please do.
http://code.google.com/p/python-nose/issues/detail?id=113
(capturedOutput vs captured_output)
http://code.google.com/p/python-nose/issues/detail?id=114 (ResultProxy
needs to proxy attributes too)
They both look like quick fixes to me, so either one would make a
great place to jump in, if you haven't yet. In both cases, work should
be done in the 0.10.0-stable branch. Which really should have been
called the 0.10-stable branch, but naming is not so much my strong
suit. ;)
Last, there are quite a few defects and enhancements in the issues
list that are all candidates for 0.11. Given the interest on both
lists in running tests in parallel, I'm +1 on including #93:
http://code.google.com/p/python-nose/issues/detail?id=114
The hard part there will be figuring out how to deal with module and
package level fixtures, not to mention plugins that might need
per-process begin() and finalize().
Otherwise, I'm pretty much neutral on what should go into 0.11. What
do you all think?
For whatever we pick for 0.11, the process will work like this:
1. Cut a branch to work in
2. Code the feature and tests in that branch
3. Post a message to the list saying that the feature is done and
telling us which branch to review
4. At least one other developer reviews the branch and declares it
ready to be merged
5. I merge the branch into trunk, then move it out of branches/ to (I
guess) branches/accepted-0.11
I'd like to wait to decide on a schedule for 0.11 until we have a
better idea of what we'll pick for the release.
That's about it for now. Thanks again all for your contributions to 0.10!
JP
Kumar McMillan
>
> Last, there are quite a few defects and enhancements in the issues
> list that are all candidates for 0.11. Given the interest on both
> lists in running tests in parallel, I'm +1 on including #93:
>
I think you meant to paste in this URL:
http://code.google.com/p/python-nose/issues/detail?id=93
>
> The hard part there will be figuring out how to deal with module and
> package level fixtures, not to mention plugins that might need
> per-process begin() and finalize().
I think we won't know what nose core needs (if anything) until there
is at least one attempt at a plugin implementation of this. I'd say
the more attempts the better and if I can find some time then I'm
interested in taking a stab at it.
> For whatever we pick for 0.11, the process will work like this:
>
> 1. Cut a branch to work in
cut a branch from trunk, right?
>
> Otherwise, I'm pretty much neutral on what should go into 0.11. What
> do you all think?
something that has been floating around in my head is to make nose
test collection completely import safe. That is, instead of importing
modules to look for tests, use abstract syntax trees [1] instead. I
noticed that otherwise this is a big problem for a default install of
a Pylons app --- if you cd into the root dir and run nosetests,
everything breaks because pylons won't let you import certain things
until the app has been set up. There is a hack to solve this by
setting the working dir to $root/tests in setup.cfg but I call that a
hack because then you can't use package level setup/teardown in
$root/tests/__init__.py ... thus there is an even greater hack whereby
test setup is coded inline to run when test/__init__.py is imported.
yuck. Import safe collection might also make nose faster.
Anyway, this might be best addressed by writing a plugin as a proof of
concept and then if it doesn't pose any problems elsewhere, consider
it for a core feature. Should I make a ticket for this?
[1] This is the module to use:
http://python.org/doc/2.2.3/lib/compiler.html ... and there are
examples of something similar in the pydoctor code :
http://codespeak.net/svn/user/mwh/pydoctor/trunk/pydoctor/astbuilder.py
jason pellerin
>
> On 10/15/07, jason pellerin <jpel...@gmail.com> wrote:
> >
> > Last, there are quite a few defects and enhancements in the issues
> > list that are all candidates for 0.11. Given the interest on both
> > lists in running tests in parallel, I'm +1 on including #93:
> >
>
> I think you meant to paste in this URL:
> http://code.google.com/p/python-nose/issues/detail?id=93
Yup. Thanks!
> I think we won't know what nose core needs [to support parallelizing tests] (if anything)
> until there is at least one attempt at a plugin implementation of this. I'd say
> the more attempts the better and if I can find some time then I'm
> interested in taking a stab at it.
My hope is that core will only need better context introspection to
support this, but we'll see. But I agree, I'd like to see some
parallelizing plugins first, for sure.
> > For whatever we pick for 0.11, the process will work like this:
> >
> > 1. Cut a branch to work in
>
> cut a branch from trunk, right?
Yes. Thanks for clarifying.
> something that has been floating around in my head is to make nose
> test collection completely import safe.
That sounds pretty cool.
> Anyway, this might be best addressed by writing a plugin as a proof of
> concept and then if it doesn't pose any problems elsewhere, consider
> it for a core feature. Should I make a ticket for this?
Yes! I can see lots of interesting possibilities for using ast trees
in test discovery and coverage reporting ("function K is called in
tests P, Q and R with the arguments... "), even if it doesn't work for
loading. And if it does work for loading and avoids the kinds of
problems that everyone has with pylons and django and other packages
that for whatever reason aren't import-safe, that would be fantastic.
JP
John J Lee
[...]
> something that has been floating around in my head is to make nose
> test collection completely import safe. That is, instead of importing
> modules to look for tests, use abstract syntax trees [1] instead. I
> noticed that otherwise this is a big problem for a default install of
> a Pylons app --- if you cd into the root dir and run nosetests,
> everything breaks because pylons won't let you import certain things
> until the app has been set up. There is a hack to solve this by
> setting the working dir to $root/tests in setup.cfg but I call that a
> hack because then you can't use package level setup/teardown in
> $root/tests/__init__.py ... thus there is an even greater hack whereby
> test setup is coded inline to run when test/__init__.py is imported.
> yuck. Import safe collection might also make nose faster.
And more correct in simpler cases, too:
http://code.google.com/p/python-nose/issues/detail?id=110
+1
> Anyway, this might be best addressed by writing a plugin as a proof of
> concept and then if it doesn't pose any problems elsewhere, consider
> it for a core feature. Should I make a ticket for this?
Why a plugin? So that more people test it? Will that really increase the
audience? Or so it's easier to write? That would surprise me. How about
just going for a spike, on a branch, freely modifying nose as you see fit?
http://c2.com/xp/SpikeSolution.html
"Any Python program, given sufficient time, will eventually grow a custom
import system, and then shed it again."
John's law of Python program evolution ;-)
John
Kumar McMillan
> And more correct in simpler cases, too:
>
> http://code.google.com/p/python-nose/issues/detail?id=110
ah, indeed.
The ticket is here: http://code.google.com/p/python-nose/issues/detail?id=116
I added a comment linking to #110. Anyone know how to create
trac-style links in Google Code comments? I've seen it done before,
but can't find docs anywhere for how. Like trac, the link to the
issue appears crossed out when it's closed.
> Why a plugin? So that more people test it? Will that really increase the
> audience? Or so it's easier to write? That would surprise me. How about
> just going for a spike, on a branch, freely modifying nose as you see fit?
>
> http://c2.com/xp/SpikeSolution.html
yeah, I think I agree now that trying to get this working directly in
core will be worth the effort. And probably not much difference in
effort either.
> "Any Python program, given sufficient time, will eventually grow a custom
> import system, and then shed it again."
>
> John's law of Python program evolution ;-)
ha!
jason pellerin
>
> First up, please welcome Michał Kwiatkowski to the dev team. Seven
> developers -- pretty good!
>
> Next, there are a couple of bug reports for 0.10.0 final that I think
> are important to fix soon, but which I probably won't get to this week
> -- if someone wants to claim them, please do.
>
> http://code.google.com/p/python-nose/issues/detail?id=113
> (capturedOutput vs captured_output)
> http://code.google.com/p/python-nose/issues/detail?id=114 (ResultProxy
> needs to proxy attributes too)
Nobody jumped on these, so I did them this afternoon. Both fixes are
in the 0.10.0-stable branch.
JP
James Casbon
> 1. Cut a branch to work in
> 2. Code the feature and tests in that branch
> 3. Post a message to the list saying that the feature is done and
> telling us which branch to review
> 4. At least one other developer reviews the branch and declares it
> ready to be merged
> 5. I merge the branch into trunk, then move it out of branches/ to (I
> guess) branches/accepted-0.11
This seems a bit heavyweight for trivial things (eg patch on #129), so
I'll just leave the patch there for someone to review. Unless anyone
objects?
jason pellerin
would be best to also include a test and a CHANGELOG update, if you
can. Or you can just wait for me to apply the patch and add those
myself. ;)
JP