nose2: project or branch?

[jason pellerin]

Now that we've handled item 1 on my list by moving to github, it's
time to talk some more about item 2. That is, what to do about the
nose2 project since unittest2's plugins branch has not been updated in
roughly a year.

The two courses of action I can see are:

1) Continue with the plan of basing nose2 on unittest2's plugins
branch and wait for it to move forward before doing anything with
nose2 (Stay a project).

2) Make nose2 less of a radical departure from nose -- steal the best
ideas from unittest2's plugins branch, avoid compatibility issues by
bundling unittest2 for older pythons, and remain fairly heavy-weight
and more standalone than had been planned, and rewrite instead of
discarding the major components that override parts of unittest (that
is, develop nose2 as a branch off of nose).

What are your thoughts? Which direction would be more fun for you as a
contributor? Which would be more useful for your as a user and plugin
author?

Thanks,

JP

[Kumar McMillan]

My gut feeling is that creating a brand new git repo for a "lightweight" nose2 that targets new Pythons [1] would gain some momentum. As nose stands right now, it takes a lot of effort to support all the old versions of Python and compiling 3.0 support is slow and annoying. I've seen new contributors get tripped up on this.

As for working off the unittest2 plugins branch, maybe it's better to use the mainline of unittest2 for now and patch in the plugin branch ideas where needed. We should probably plan to throw way that code when plugin support reaches the unittest2 mainline.

It would be pretty neat if all of nose2 core was implemented using the plugin API.

[1] maybe start nose2 with Python 3.0 and try to support new-ish versions all in one library without any compilers (mock does this I think). We can declare unittest2 as a dependency since it's on PyPI http://pypi.python.org/pypi/unittest2

--
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.

[jason pellerin]

Hm, interesting. So basically, if I follow, you're saying start with
the tiny bit of a project we have (https://github.com/nose-devs/nose2)
but:

1) bundle mainline unittest2 like django does (or just have it as a
requirement?)
2) overlay a plugin system like the one from the plugins branch ...
with a compatible api for plugin authors, if possible ... but not
actually use the plugins branch implementation
3) try to target python 2.6(?)-3.x with the same code base
4) revise the plan when/if the unittest2 plugins branch lands

That seems reasonable to me. When things will get hairy is the
overlaying of a plugin system. As we found with nose, there's really
no clean way to do that -- you have to monkeypatch or override
basically everything, you have to wrap test cases, etc. But the only
way to avoid that is to continue in a holding pattern until the
unittest2 plugins branch starts moving again.

JP

[Kumar McMillan]

On Fri, Dec 23, 2011 at 8:28 AM, jason pellerin <jpel...@gmail.com> wrote:

Hm, interesting. So basically, if I follow, you're saying start with
the tiny bit of a project we have (https://github.com/nose-devs/nose2)
but:

1) bundle mainline unittest2 like django does (or just have it as a
requirement?)
2) overlay a plugin system like the one from the plugins branch ...
with a compatible api for plugin authors, if possible ... but not
actually use the plugins branch implementation
3) try to target python 2.6(?)-3.x with the same code base
4) revise the plan when/if the unittest2 plugins branch lands

Yep, that gets my vote assuming it's all doable of course. I think we can just list unittest2 as a requirement so it gets pulled in with pip or easy_install. Django is fond of "bundling" everything but that's sort of extreme, Nose is a package-index friendly module :)
 

That seems reasonable to me. When things will get hairy is the
overlaying of a plugin system. As we found with nose, there's really
no clean way to do that -- you have to monkeypatch or override
basically everything, you have to wrap test cases, etc. But the only
way to avoid that is to continue in a holding pattern until the
unittest2 plugins branch starts moving again.

It would be a good test of unittest2's extensibility. One approach could be that in every place we have to monkey patch something, we make sure there is good test coverage then open issues and/or start patches to send upstream to unittest2.
 

[jason pellerin]

On Friday, December 23, 2011, Kumar McMillan <kumar.m...@gmail.com> wrote:
>
> It would be a good test of unittest2's extensibility. One approach could be that in every place we have to monkey patch something, we make sure there is good test coverage then open issues and/or start patches to send upstream to unittest2.

Well, that's sort of the rub. Unittest2 is just as extensible as unittest... Not very. Subclass and override. So we'd have to do basically the same things in nose2 as in nose -- override TestProgram and the loader and runner and result and wrap all test cases so we have places from which to fire our plugin hooks. We can do a better job of it, but it will basically be the same job nose does.

But given the alternatives.... Still probably the best available plan.

JP