[pytest-dev] plugin status page

[holger krekel]

Hi Bruno, all,

i've brought your initial work online at the "dev" pytest pages:

    http://pytest.org/dev/plugins_index.html

I think it's a good start, thanks!

My comments and wishes (others may comment as well!):

- i'd collapse NAME and VERSION columns to save space, i.e.
  "pytest-bdd-0.6.1".

- we should try to collect repository locations. maybe parsing
  for github/bitbucket urls would yield most of them automatically?
  Maybe we need to add some manually.

- what about adding download numbers?

- as to code organisation: you can leave it as is for now or (maybe
  better) put all code and generated files into a dedicated directory.

A very interesting bit will be the "2.4.2 compat" and "dev" compat 
determination.  In fact, i think "devpi" should help with that although
i guess i need to improve some things.  You can give using it a try
with these steps:

    pip install devpi-client
    devpi use http://devpi.net/root/pypi
    devpi test -e py27 pytest-pep8

The last bit should download the pypi-version of pytest-pep8, unpack
it and run tox for the "py27" environment and then post back test
results (as a json file) to the devpi.net server. You can also ask about
plugin "test" status:

    devpi list pytest-pep8

I just found out that this doesn't work for "pytest-flakes" yet
although that does have a tox.ini.  need to look into what's going on.
In principle, devpi-server (an instance of which you are using above),
provides a lot of detailed test info as a json, see here for example:

    http://devpi.net/+tests/6199353734615fde47d1fbfef1ebc737/toxresult

The test results are stored as per the package MD5 at the moment.
The whole test/list/json machinery of devpi needs some more work
to become really nice, but it should already help as currently implemented,
maybe best by using "devpi list" and filing feature requests against it :)

For testing "development" versions, it should be enough to upload
e.g. a "pytest-2.4.3.dev1" to a private index and then re-run the script
that invokes something like the above devpi commands for all of the
plugins.

Now, for the plugins that don't have a tox.ini we could supply one
out of band.  For this "devpi test" would grow an option like
"--toxini=mytox.ini" and would use that instead of expecting one
in the downloaded unpacked distribution file.  This tox.ini would probably
just have a testenv that does "py.test --version" and "py.test --help"
to see if something broke by just installing the plugin.

So much for now,
holger