<div dir="ltr">Hi Holger,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 4, 2013 at 6:25 PM, holger krekel <span dir="ltr"><<a href="mailto:holger@merlinux.eu" target="_blank">holger@merlinux.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>> Are you interested in displaying compatibility to several py.test versions,<br>
> or only to the latest one?<br>
<br>
</div>ideally latest release and trunk ...<br></blockquote><div><br></div><div>Fair enough. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>> and some way to re-generate this information (especially the test status).<br>
> > I guess we could start with considering plugins that have a tox.ini<br>
> > and then write a script to download the plugin, unpack it, run tests etc.<br>
> ><br>
><br>
> I considered this, but then I realize we might have to implement several<br>
> features to support that, like installing dependencies: pytest-qt for<br>
> instance requires PySide, which must be installed for it to run its own<br>
> tests. Other plugins might have other requirements to run its tests (like<br>
> having a browser open for headless testing), which would have to be<br>
> supported as well and so on. I fear we would have to implement a lot of<br>
> infrastructure similar to what <a href="http://travis-ci.org" target="_blank">travis-ci.org</a> or d<br>
</div>> <<a href="http://crate.io" target="_blank">http://crate.io</a>>rone.iodoes for example.<br>
<div>><br>
> Perhaps we could adopt a solution similar to <a href="http://coveralls.io" target="_blank">coveralls.io</a>, in which the<br>
> author is responsible to upload coverage data, and the site collects and<br>
> displays that information. We could provide a script or code snippet to be<br>
> included by the plugin author in he's C.I of choice that would generate and<br>
> upload pytest-compatibility information. This could be easily hosted in a<br>
> PaaS like Heroku.<br>
><br>
> We would have to count on plugin authors' contribution to the system for it<br>
> to work on this scheme, of course.<br>
<br>
</div>I wonder how difficult most plugins really are to setup.<br>
PyQT might be difficult but OTOH many others should just be fine.<br>
<br>
And pushing the responsibility for performing tests and uploading results<br>
still would not get the benefit of testing current plugin releases<br>
against a new core pytest release (which can break many plugins whereas<br>
a new plugin release can just break that plugin :). </blockquote><div><br></div><div>Yes, having to rely on package authors to update their CI system to use a new pytest version would defeat the purpose of the status page. :/</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So i'd think it's best to check how many of the plugins even provide tests.<br></blockquote><div><br></div><div>Hmm, of that I have no idea...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
But even just collecting the other information i mentioned (without<br>
the test status / running questions) would already be helpful, btw.<br></blockquote><div><br></div><div>That seems simple enough, a script that queries pypi and extracts this information could be used to generate a page and/or statistics. </div>
<div><br></div><div>From my understanding you would like a page to accomplish two things:</div><div><br></div><div>1. A list of known py-test plugins and their py27/py33 status.</div><div>2. If the plugins work against latest pytest and against trunk, so pytest developers know if they're breaking existing plugins (intentionally or not).</div>
<div><br></div><div>Is that correct?</div><div><br></div><div>I'm trying to figure out a semi automatic way to accomplish both. :)</div><div><br></div><div>Cheers,</div><div>Bruno<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
cheers,<br>
holger<br>
<div><div><br>
> The other part is how to present this info, but e.g. a CSV file<br>
> > can be rendered by sphinx and the main docs could include it<br>
> > or we make a separate page if need be.<br>
><br>
><br>
> > thanks for considering to help!<br>
> ><br>
><br>
> Glad to. :)<br>
><br>
> Best Regards,<br>
> Bruno<br>
><br>
> ><br>
> > holger<br>
> ><br>
> > > Cheers,<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On Fri, Oct 4, 2013 at 10:09 AM, holger krekel <<a href="mailto:holger@merlinux.eu" target="_blank">holger@merlinux.eu</a>><br>
> > wrote:<br>
> > ><br>
> > > ><br>
> > > > I just did three pytest plugin releases to get out a few minor<br>
> > > > fixes and improvements. see below. As far as i am aware most<br>
> > > > existing plugins (as well as the new releases here) should be<br>
> > > > compatible to pytest-2.4.2. Some plugins like pytest-capturelog<br>
> > > > have seen their latest release three years ago but remain functional.<br>
> > > > A good sign that the plugin system is reasonable i guess.<br>
> > > ><br>
> > > > If someone wants to help with organizing plugin compatibility<br>
> > > > tests and maintaining a status page, i'd really appreciate that.<br>
> > > > With over 50 existing plugins it's not easy to stay on top.<br>
> > > > The current <a href="http://pytest.org" target="_blank">pytest.org</a> page is only a start:<br>
> > > ><br>
> > > > <a href="http://pytest.org/latest/plugins.html#extplugins" target="_blank">http://pytest.org/latest/plugins.html#extplugins</a><br>
> > > ><br>
> > > > and here is the full pypi list:<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > <a href="https://pypi.python.org/pypi?%3Aaction=search&term=pytest-&submit=search" target="_blank">https://pypi.python.org/pypi?%3Aaction=search&term=pytest-&submit=search</a><br>
> > > ><br>
> > > > there are also some github/bitbucket-only plugins, in addition.<br>
> > > ><br>
> > > > And finally a note to plugin authors: please be subscribed<br>
> > > > to pytest-dev and post new plugin releases here.<br>
> > > ><br>
> > > > best,<br>
> > > > holger<br>
> > > ><br>
> > > > pytest-xdist-1.9:<br>
> > > ><br>
> > > > - changed LICENSE to MIT<br>
> > > ><br>
> > > > - fix duplicate reported test ids with --looponfailing<br>
> > > > (thanks Jeremy Thurgood)<br>
> > > ><br>
> > > > - fix pytest issue41: re-run tests on all file changes, not just<br>
> > > > randomly select ones like .py/.c.<br>
> > > ><br>
> > > > - fix pytest issue347: slaves running on top of Python3.2<br>
> > > > will set PYTHONDONTWRITEYBTECODE to 1 to avoid import concurrency<br>
> > > > bugs.<br>
> > > ><br>
> > > > pytest-xprocess-0.8:<br>
> > > ><br>
> > > > - support python3 (tested on linux/win32)<br>
> > > ><br>
> > > > - split out pytest independent process support into xprocess.py<br>
> > > ><br>
> > > > - add info.kill() method and some smaller refactoring<br>
> > > ><br>
> > > > - fix various windows related Popen / killing details<br>
> > > ><br>
> > > > - add tests<br>
> > > ><br>
> > > ><br>
> > > > pytest-pep8:<br>
> > > ><br>
> > > > - use pytest-2.4.2 node.add_marker() API for adding "pep8" marker<br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > Pytest-dev mailing list<br>
> > > > <a href="mailto:Pytest-dev@python.org" target="_blank">Pytest-dev@python.org</a><br>
> > > > <a href="https://mail.python.org/mailman/listinfo/pytest-dev" target="_blank">https://mail.python.org/mailman/listinfo/pytest-dev</a><br>
> > > ><br>
> ><br>
</div></div></blockquote></div><br></div></div>