1.3.0 release?
16 views
Skip to first unread message
John Szakmeister
Nov 28, 2012, 7:35:36 PM11/28/12
to nose...@googlegroups.com
Hi Jason,
I was wondering if I could help push along a 1.3.0 release? As you
saw, I've been going through some of the outstanding pull requests
trying to test and vet them.
I think #570 can be closed. I filed a new one (#586) that adds the
ability to skip byte-compiling, but did it as an option.
I looked at #573 (ignore __pycache__ directories), and it looks good
to me. I also went back and re-looked at #563 (Fix test_address's
checking for builtins), and I believe it's good to go too. I had
added tests, and double-checked it on both Python 2 and Python 3.
I spent some time looking at #582 (Stop xunit from completely dying if
it encounters an error), but the approach taken there is more of a
workaround than a fix. It's not entirely how the user encounters this
problem. I did look at several code paths that lead up to addError()
and I couldn't find a spot where the we're doing something wrong...
but someone is, I believe.
#489 (nose.tools now imports fail and fail_* methods from
unittest.TestCase) has been hanging out there a while, but the tests
only pass on Python 2.7 or better. Not sure what to do there. The
approach works fine in Python 2.5 and 2.6, it just that all the
methods that it's trying to expose aren't available in < 2.7.
#543 (Added assert_not_raises) looks pretty close, but removes
nosetests.1, which I think is an error. I can fix it up, if you like.
It was a bit sloppy in how it was done, though I think the final
result is pretty close. It also touched .gitignore, and some
documentation that it shouldn't have.
#533 (Made tools.raises support 'with statement' and exception
checker.) looks ready to go. The author did add tests, and they pass,
with the exception of the PyPy one that times out.
BTW, I did spend some time looking at that timeout. I'm still not
sure what's happening there, but it smells like a PyPy problem, versus
a problem with the test. I'm not sure what to do about that.
If you like I can create a branch in my repo that folds in the PRs
that I think are ready and publish that. I imagine NEWS needs to be
updated too. Is there anything I can do to help move things along?
As I mentioned before, we've been building on top a tester on top of
Nose, and it'd be nice to have a new stable release of nose.
-John
I was wondering if I could help push along a 1.3.0 release? As you
saw, I've been going through some of the outstanding pull requests
trying to test and vet them.
I think #570 can be closed. I filed a new one (#586) that adds the
ability to skip byte-compiling, but did it as an option.
I looked at #573 (ignore __pycache__ directories), and it looks good
to me. I also went back and re-looked at #563 (Fix test_address's
checking for builtins), and I believe it's good to go too. I had
added tests, and double-checked it on both Python 2 and Python 3.
I spent some time looking at #582 (Stop xunit from completely dying if
it encounters an error), but the approach taken there is more of a
workaround than a fix. It's not entirely how the user encounters this
problem. I did look at several code paths that lead up to addError()
and I couldn't find a spot where the we're doing something wrong...
but someone is, I believe.
#489 (nose.tools now imports fail and fail_* methods from
unittest.TestCase) has been hanging out there a while, but the tests
only pass on Python 2.7 or better. Not sure what to do there. The
approach works fine in Python 2.5 and 2.6, it just that all the
methods that it's trying to expose aren't available in < 2.7.
#543 (Added assert_not_raises) looks pretty close, but removes
nosetests.1, which I think is an error. I can fix it up, if you like.
It was a bit sloppy in how it was done, though I think the final
result is pretty close. It also touched .gitignore, and some
documentation that it shouldn't have.
#533 (Made tools.raises support 'with statement' and exception
checker.) looks ready to go. The author did add tests, and they pass,
with the exception of the PyPy one that times out.
BTW, I did spend some time looking at that timeout. I'm still not
sure what's happening there, but it smells like a PyPy problem, versus
a problem with the test. I'm not sure what to do about that.
If you like I can create a branch in my repo that folds in the PRs
that I think are ready and publish that. I imagine NEWS needs to be
updated too. Is there anything I can do to help move things along?
As I mentioned before, we've been building on top a tester on top of
Nose, and it'd be nice to have a new stable release of nose.
-John
jason pellerin
Dec 5, 2012, 9:08:49 AM12/5/12
to nose...@googlegroups.com
Hi,
Sorry for the long delayed reply. If you'd like to put together a 1.3 release candidate branch, that would be a HUGE help. If you include everything you think is ready, and update the changelog and NEWS, I will definitely make time in the next 7-10 days to review and merge the branch and push out a 1.3 release.
Thank you!
JP
-John
--
You received this message because you are subscribed to the Google Groups "nose-dev" group.
To post to this group, send email to nose...@googlegroups.com.
To unsubscribe from this group, send email to nose-dev+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nose-dev?hl=en.
John Szakmeister
Dec 6, 2012, 5:47:56 AM12/6/12
to nose...@googlegroups.com
On Wed, Dec 5, 2012 at 9:08 AM, jason pellerin <jpel...@gmail.com> wrote:
> Hi,
>
> Sorry for the long delayed reply. If you'd like to put together a 1.3
> release candidate branch, that would be a HUGE help. If you include
> everything you think is ready, and update the changelog and NEWS, I will
> definitely make time in the next 7-10 days to review and merge the branch
> and push out a 1.3 release.
Sounds good Jason. I'll start putting something together in the next
> Hi,
>
> Sorry for the long delayed reply. If you'd like to put together a 1.3
> release candidate branch, that would be a HUGE help. If you include
> everything you think is ready, and update the changelog and NEWS, I will
> definitely make time in the next 7-10 days to review and merge the branch
> and push out a 1.3 release.
few days, and ping you when it's ready.
> Thank you!
You're very welcome!
-John
John Szakmeister
Dec 7, 2012, 3:52:50 PM12/7/12
to nose...@googlegroups.com
On Wed, Dec 5, 2012 at 9:08 AM, jason pellerin <jpel...@gmail.com> wrote:
> Hi,
>
> Sorry for the long delayed reply. If you'd like to put together a 1.3
> release candidate branch, that would be a HUGE help. If you include
> everything you think is ready, and update the changelog and NEWS, I will
> definitely make time in the next 7-10 days to review and merge the branch
> and push out a 1.3 release.
Just wanted to touch base real quick. I've been putting a branch
>
> Sorry for the long delayed reply. If you'd like to put together a 1.3
> release candidate branch, that would be a HUGE help. If you include
> everything you think is ready, and update the changelog and NEWS, I will
> definitely make time in the next 7-10 days to review and merge the branch
> and push out a 1.3 release.
together with a few more pull requests integrated. I'm trying to go
back and see which ones I think are the most serious, and see if I
can't shepherd them in somehow. I did run across one problem. I
noticed this morning that 3 bugs are marked as blockers. One of them
is fixed (#554: setup.py does not install nose.tools).
Today, I've been working on #566 (python 3.3 test failures). Some of
the output in Python 3.3 has changed slightly, which was breaking some
doctests. I fixed a few doctests, but there are a couple more that
need fixing. In this case, the ImportError string has changed from:
ImportError: No module named apackagethatdoesntexist
to:
ImportError: No module named 'apackagethatdoesntexist'
The other is a recursion depth problem. I haven't managed to get to
the bottom of that problem yet, but I hope to soon.
There's one more ticket marked as a blocker: #556 (setup.py nosetests
issue). I haven't looked at this one at all yet.
At any rate, I wanted to touch base and let you know where things are
at. I've started putting a CHANGELOG together as well. I hope that
some time next week we're much closer.
-John
John Szakmeister
Dec 8, 2012, 5:36:01 AM12/8/12
to nose...@googlegroups.com
On Fri, Dec 7, 2012 at 3:52 PM, John Szakmeister <jo...@szakmeister.net> wrote:
[snip]
> The other is a recursion depth problem. I haven't managed to get to
> the bottom of that problem yet, but I hope to soon.
I'm getting closer on this one, but it's kind of nasty. There seems
to be something bad triggering between
"functional_tests/test_buggy_generators.py" and
"functional_tests/test_namespace_pkg.py". The latter is what dies
from exceeding the recursion depth, but it doesn't exhibit the problem
when run on its own. If you run test_buggy_generators with it though,
the two together cause the problem to surface. It's not clear to me
what the bad interaction is though. One weird problem that I see is
that log statements start getting repeated multiple times, when I
turned on debug logging in nose/loader.py (where the test dies). At
first, it's expected once per execution. But then it picks up, and
then it's two, then three... all the way up to 14 times per logging
statement. It's really strange.
FWIW, I've been running nose in a Python 3.3 virtualenv, with this command line:
python3.3 setup.py build_tests && \
python3.3 selftest.py functional_tests/test_buggy_generators.py \
functional_tests/test_namespace_pkg.py
I put my branch on GitHub:
<https://github.com/jszakmeister/nose/tree/python-3.3-fixes>
It's based on the 1.3.0-candidate branch I'm putting together:
<https://github.com/jszakmeister/nose/tree/1.3.0-candidate>
The good news is that this is the only Python 3.3 error left. :-)
-John
[snip]
> Today, I've been working on #566 (python 3.3 test failures). Some of
> the output in Python 3.3 has changed slightly, which was breaking some
> doctests. I fixed a few doctests, but there are a couple more that
> need fixing. In this case, the ImportError string has changed from:
>
> ImportError: No module named apackagethatdoesntexist
>
> to:
>
> ImportError: No module named 'apackagethatdoesntexist'
I've got this fixed now.
> the output in Python 3.3 has changed slightly, which was breaking some
> doctests. I fixed a few doctests, but there are a couple more that
> need fixing. In this case, the ImportError string has changed from:
>
> ImportError: No module named apackagethatdoesntexist
>
> to:
>
> ImportError: No module named 'apackagethatdoesntexist'
> The other is a recursion depth problem. I haven't managed to get to
> the bottom of that problem yet, but I hope to soon.
to be something bad triggering between
"functional_tests/test_buggy_generators.py" and
"functional_tests/test_namespace_pkg.py". The latter is what dies
from exceeding the recursion depth, but it doesn't exhibit the problem
when run on its own. If you run test_buggy_generators with it though,
the two together cause the problem to surface. It's not clear to me
what the bad interaction is though. One weird problem that I see is
that log statements start getting repeated multiple times, when I
turned on debug logging in nose/loader.py (where the test dies). At
first, it's expected once per execution. But then it picks up, and
then it's two, then three... all the way up to 14 times per logging
statement. It's really strange.
FWIW, I've been running nose in a Python 3.3 virtualenv, with this command line:
python3.3 setup.py build_tests && \
python3.3 selftest.py functional_tests/test_buggy_generators.py \
functional_tests/test_namespace_pkg.py
I put my branch on GitHub:
<https://github.com/jszakmeister/nose/tree/python-3.3-fixes>
It's based on the 1.3.0-candidate branch I'm putting together:
<https://github.com/jszakmeister/nose/tree/1.3.0-candidate>
The good news is that this is the only Python 3.3 error left. :-)
-John
John Szakmeister
Dec 21, 2012, 4:23:56 PM12/21/12
to nose...@googlegroups.com
> I put my branch on GitHub:
> <https://github.com/jszakmeister/nose/tree/python-3.3-fixes>
>
> It's based on the 1.3.0-candidate branch I'm putting together:
> <https://github.com/jszakmeister/nose/tree/1.3.0-candidate>
>
> The good news is that this is the only Python 3.3 error left. :-)
Just to keep folks in the loop. I think all the Python 3.3 issues are
> <https://github.com/jszakmeister/nose/tree/python-3.3-fixes>
>
> It's based on the 1.3.0-candidate branch I'm putting together:
> <https://github.com/jszakmeister/nose/tree/1.3.0-candidate>
>
> The good news is that this is the only Python 3.3 error left. :-)
now fixed.
There is one other issue marked as a blocker (#556: setup.py nosetests
issue) that I'll take a look at over the holidays. I'll also pick up
the work of getting a release candidate branch together. I had hoped
to have it all done, but I've been under-the-weather for a week now.
Jason, I know the multiprocess stuff is driving you a bit crazy and
would like to see the tests get better. I'm willing to hunt the bugs
down and fix them as I trip across them. The biggest issue that I see
is that I have test output from several processes all being sent to a
single stream, and I just don't see how we're going to be able to
reliably assert anything with that setup. Do you have any ideas on
this front? I'm just not sure where to go with it. To have reliable
output, it would mean that all the subprocesses would have to ship
their output back to the main process, and it could output the data in
a way that doesn't intermix. That seems like a large change, and I'm
not sure I'm willing to sign up for that one (I don't use that
feature). Is there something short of that we can do to help us get
more reliable test output?
Happy holidays!
-John
jason pellerin
Dec 23, 2012, 9:04:18 AM12/23/12
to nose...@googlegroups.com
Jason, I know the multiprocess stuff is driving you a bit crazy and
would like to see the tests get better. I'm willing to hunt the bugs
down and fix them as I trip across them. The biggest issue that I see
is that I have test output from several processes all being sent to a
single stream, and I just don't see how we're going to be able to
reliably assert anything with that setup.
I agree. I think the only real solution will be to totally rewrite any test that does that, but that's much easier said than done. Way beyond what I can commit to, given the very limited amount of time I have to work on nose these days. So unless we can get a patch, or many patches that chip away at the problem, we'll either have to live with it, or maybe disable those tests on travis somehow.
JP
John Szakmeister
Dec 23, 2012, 10:19:49 AM12/23/12
to nose...@googlegroups.com
though. I think the issue is that we have to asynchronous process
writing to stderr, and there's just no predictability in that. :-( We
might be able to do something about not having them run on Travis
though. I'll look into it.
BTW, my 1.3.0-candidate branch is getting close:
<https://github.com/jszakmeister/nose/tree/1.3.0-candidate>
I've updated the CHANGELOG. I was going to try and fix the 'python
setup.py nosetests --tests' problem... apparently the 2to3 support is
what created the issue. I tried pinging the person who submitted the
fix to see if I could get a better rationale for why we're now passing
an argument internally. We'll see what they have to say.
Thanks for taking the time to look at this stuff Jason!
-John
PS If you give me permission in GitHub, I believe we can close some
tickets. I tried commenting on the ones that I think are fixed, or
should be closed. I realize it can get lost in the noise though.
jason pellerin
Jan 3, 2013, 10:03:22 AM1/3/13
to nose...@googlegroups.com
I added you to the nose team on nose-devs, so you should have push access to the main repos, and (I think) have the ability to edit and close issues. Thank you again for jumping in to help, I really appreciate it. And happy new year! :)
JP
John Szakmeister
Jan 3, 2013, 11:31:37 AM1/3/13
to nose...@googlegroups.com
On Thu, Jan 3, 2013 at 10:03 AM, jason pellerin <jpel...@gmail.com> wrote:
> I added you to the nose team on nose-devs, so you should have push access to
> the main repos, and (I think) have the ability to edit and close issues.
> Thank you again for jumping in to help, I really appreciate it. And happy
> new year! :)
Thank you! And Happy New Year to you as well!
> I added you to the nose team on nose-devs, so you should have push access to
> the main repos, and (I think) have the ability to edit and close issues.
> Thank you again for jumping in to help, I really appreciate it. And happy
> new year! :)
-John
John Szakmeister
Jan 8, 2013, 2:29:45 PM1/8/13
to nose...@googlegroups.com
I just wanted to give a heads up where everything is at.
I was offline during the holidays, and I'm trying to pick things back
up. We still have one issue marked as a blocker, but I'm not sure I'm
the right person to fix it (my 2to3-fu is pretty low at the moment).
If someone knows of a good fix for this, I'd appreciate it:
<https://github.com/nose-devs/nose/issues/556>
I've updated my 1.3.0-candidate branch with everything that I think
should go in. Depending on the time I get, and the state of the
patches, I might try and squeeze a few more fixes in. For those
interested, the branch is here:
<https://github.com/jszakmeister/nose/tree/1.3.0-candidate>
I've been holding off on filing a PR until the other blocker bug gets
fixed. Again, if someone can spare some cycles and get that fixed, it
would be fantastic.
-John
I was offline during the holidays, and I'm trying to pick things back
up. We still have one issue marked as a blocker, but I'm not sure I'm
the right person to fix it (my 2to3-fu is pretty low at the moment).
If someone knows of a good fix for this, I'd appreciate it:
<https://github.com/nose-devs/nose/issues/556>
I've updated my 1.3.0-candidate branch with everything that I think
should go in. Depending on the time I get, and the state of the
patches, I might try and squeeze a few more fixes in. For those
interested, the branch is here:
<https://github.com/jszakmeister/nose/tree/1.3.0-candidate>
I've been holding off on filing a PR until the other blocker bug gets
fixed. Again, if someone can spare some cycles and get that fixed, it
would be fantastic.
-John
Reply all
Reply to author
Forward
0 new messages