subunit should contain a top-level 'setup.py'

So, subunit is not primarily a python program; its C and C++ and shell and perl and python. Using setup.py for the build system wouldn't work well.

We could use setup.py for just the python parts, but someone would need to write appropriate glue such that:
make
make dist
make distcheck
make check
make clean
make distclean
make install

all work appropriately, and so that configure options for where to install (--prefix etc) take effect appropriately.

You are right, I should register on pypi; I've been meaning to lookup the API glue to do that without a setup.py. Lastly, I guess we can simulate a bdist or something fairly easily?

Oh, another option would be to make the python bindings and code a separate project; I don't see that really helping 'easy install' though, if a C protocol parser (for speed) is added. (which it might be, who knows ;)).

I released a nosetests plugin to generate subunit output: http://pypi.python.org/pypi/nose-subunit/

however, I can't specify subunit as a dependency, because it's not easy-installable

I second the idea of separating the python binding into a separate module at least, so it's easy-installable

a side node: with setup.py, you can actually compile C code, such as cjson http://pypi.python.org/pypi/python-cjson

Hi, let me say I'll definitely merge something in this direction, I
appreciate the benefits easy_install has for many developers, even
though I don't use it myself.

The compiling of C stuff is important if/when subunit gets a C parser
- but such a parser will be vanilla C, because that way it can be used
in other languages more easily. So we'd have:

c/libsubunit (already exists) with a parser in it
python/subunit/_subunit.so - Python adaption layer for the parser.
python/subunit/*.py

However that isn't the case now, and I'm likely to keep a pure python
parser for reference regardless, so it shouldn't block this.

The main reason I haven't merged it yet is simply bandwidth - I've
been moving house and country and that consumes a lot of time.

-Rob

let me know whether I can be of help.

as it stands now, for me at least, I don't actually use anything other than the python implementation of the subunit package. I think the python package is self-sufficient.

The setup.py on my branch doesn't do any C compilation, because there isn't
(yet) any C which is relevant for the Python bindings. If / when such an
implementation lands, I will be glad to help get the extension compilable
inside setup.py.

will it be possible to just install this with:
    easy_install subunit

so it can be specified in other easy-installable python packages as dependency?

I would expect so - easy_install python-subunit once its on pypi (and
I'll put it on pypi when the next release happens, which should be
quite soon, just hoping to get the discover support integrated in.

good to know, thanks

btw: what's discover support? (any online document/specification?)

'discover' is the name of the python module that unittest2, and
unittest in python 2.7 and 3.2 use for test discovery. testtools which
subunit builds on has just added support for discover, and the subunit
patch is pretty close too.

-Rob