<div dir="ltr">Hi Holger,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 24, 2013 at 4:52 AM, 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">Hi Bruno,<br>
<div class="im"><br>
On Wed, Oct 23, 2013 at 21:51 -0200, Bruno Oliveira wrote:<br>
> Hi Holger, all,<br>
><br>> <snip><br>
> I have updated the script to create a tox.ini file that just uses "py.test<br>
> --help" as a test command for those packages that don't have one. Now the<br>
> script tests all pytest plugins in pypi, please take a look at the summary<br>
> at the bottom of the page:<br>
><br>
> <a href="https://www.travis-ci.org/nicoddemus/pytest-plugs/jobs/12959702" target="_blank">https://www.travis-ci.org/nicoddemus/pytest-plugs/jobs/12959702</a><br>
<br>
</div>looks good! I guess having a py27 and py33 row would be great<br>
to also determine py3 compatibility/installability.<br></blockquote><div><br></div><div>Those are already in place as different build jobs, please take a look:</div><div><br></div><div><a href="https://www.travis-ci.org/nicoddemus/pytest-plugs">https://www.travis-ci.org/nicoddemus/pytest-plugs</a></div>
<div><br></div><div>Currently we have py27 and py33 against pytest 2.3.5 and 2.4.2. Adding more python/pytest versions is easy, we just have to add them to the .travis file. :)</div><div><br></div><div><a href="https://github.com/nicoddemus/pytest-plugs/blob/master/.travis.yml">https://github.com/nicoddemus/pytest-plugs/blob/master/.travis.yml</a><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">
<div class="im"><br>
> I guess it would be useful to identify which plugins are using just<br>
> "py.test --help" as smoke test and which ones have real tests, since the<br>
> former doesn't guarantee that the plugin actually works on that<br>
> python/pytest combination.<br>
><br>
> I looked into devpi to simplify the download/unpack/test process and<br>
> stumbled in a minor roadblock: is there anyway to provide a tox.ini file<br>
> for those plugins that don't have one? This is the only issue I see right<br>
> now with using devpi for this particular application.<br>
<br>
</div>Now, but i am going to add a "devpi test -c path-to-ini" option today<br>
and plan to release devpi-1.2 real soon now. I'll get back here when it's<br>
implemented.<br></blockquote><div><br></div><div>Perfect, that would greatly simplify things. Let me know if there is anything I can do to help.</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">
<div class="im">> So, what do you think of the idea of using <a href="http://devpi.net" target="_blank">devpi.net</a> to host test results<br>
> and add an endpoint to the API to provide test status images? Or should I<br>
> create another app to do this?<br>
<br>
</div>What do you mean with "test status images"?</blockquote><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">
In general i am open to extending devpi-server to provide more test-status<br>
info -- just didn't have a chance to think about it in detail yet.<br>
I guess we could take the plugin testing bits as a starting point.<br></blockquote><div><br></div><div>I mean like those badge images served by travis that give the current build status, for example:</div><div><br></div>
<div><a href="https://secure.travis-ci.org/hpk42/pytest.png">https://secure.travis-ci.org/hpk42/pytest.png</a><br></div><div><br></div><div>I think we can follow the same approach, generating a badge that gives the full compatibility status, like a single "py 2.6 2.7 | pytest 2.3.5 | compatible" image, or even multiple images. </div>
<div><br></div><div>But I guess this is too specific to pytest...</div><div><br></div><div>Cheers,</div><div>Bruno.</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">
<br>
best,<br>
holger<br>
<div class=""><div class="h5"><br>
> Cheers,<br>
> Bruno.<br>
><br>
><br>
> > I found the reason for that (http vs https) and now the job runs against<br>
> > Python 2.6, 2.7, 3.2 and 3.2.<br>
> ><br>
> > Thanks! Got back but caught a flue ...<br>
> >><br>
> ><br>
> > It happens, hope you get better soon. :)<br>
> ><br>
> > Cheers,<br>
> > Bruno.<br>
> ><br>
> ><br>
> > On Sun, Oct 20, 2013 at 3:52 AM, holger krekel <<a href="mailto:holger@merlinux.eu">holger@merlinux.eu</a>> wrote:<br>
> ><br>
> >> On Mon, Oct 14, 2013 at 23:52 -0300, Bruno Oliveira wrote:<br>
> >> > > > ><br>
> >> > > > > - i'd collapse NAME and VERSION columns to save space, i.e.<br>
> >> > > > > "pytest-bdd-0.6.1".<br>
> >> > > > ><br>
> >> > > > > - what about adding download numbers?<br>
> >> > > > ><br>
> >> > > > > - as to code organisation: you can leave it as is for now or<br>
> >> (maybe<br>
> >> > > > > better) put all code and generated files into a dedicated<br>
> >> directory<br>
> >> > > ><br>
> >> > ><br>
> >> ><br>
> >> > Done, opened a PR for discussion and reviewing. :)<br>
> >><br>
> >> only got to it now, looks good so far!<br>
> >><br>
> >> > > > > - we should try to collect repository locations. maybe parsing<br>
> >> > > > > for github/bitbucket urls would yield most of them<br>
> >> automatically?<br>
> >> > > > > Maybe we need to add some manually.<br>
> >> > > > ><br>
> >> > > ><br>
> >> > > > May I ask why we would need the repository locations? I mean, to<br>
> >> work on<br>
> >> > > > the compatibility feature we can work directly with packages in<br>
> >> pypi or<br>
> >> > > > devpi...<br>
> >> > ><br>
> >> > > purely for the person reading the page and wanting to look at the code<br>
> >> > > or do a PR.<br>
> >> > ><br>
> >> ><br>
> >> > Oh I see! Well, parsing the urls seems problematic, because we also<br>
> >> have to<br>
> >> > take in account the username ("hpk42/pytest" for example). I looked at<br>
> >> the<br>
> >> > GitHub and BitBucket's rest APIs to see if we could use them for<br>
> >> searching,<br>
> >> > but it seems only GitHub at the moment has a search API (and in beta<br>
> >> stage<br>
> >> > at that).<br>
> >> ><br>
> >> > I think we will have to maintain the repository list manually. Package<br>
> >> > authors can help as well by simply opening PRs adding repositories for<br>
> >> > their plugins I guess.<br>
> >><br>
> >> What about generating a "plugin details " page for each plugin so we don't<br>
> >> have to think too hard about what to put in the index page?<br>
> >><br>
> >> > > A very interesting bit will be the "2.4.2 compat" and "dev" compat<br>
> >> > > > <snip><br>
> >> > ><br>
> >> ><br>
> >> > Some late night quick hacking and I have come up with this proof of<br>
> >> concept:<br>
> >> ><br>
> >> > <a href="https://www.travis-ci.org/nicoddemus/pytest-plugs" target="_blank">https://www.travis-ci.org/nicoddemus/pytest-plugs</a><br>
> >> ><br>
> >> > As it is right now it serves only as a prove of concept, of course. The<br>
> >> > idea is using travis to handle running things for us, driving it using a<br>
> >> > script that downloads and run tests using tox. We can then collect json<br>
> >> > information from that and POST those results back to devpi. Also we can<br>
> >> use<br>
> >> > its build matrix to test against different pytest versions, for example.<br>
> >><br>
> >> Hum, interesting. Is this mainly to make use of travis-ci's build hosts?<br>
> >> What is the advantage over just invoking "devpi test PLUGIN-NAME" from the<br>
> >> script to automate the download/unpack/test/post-results steps?<br>
> >><br>
> >> > I guess we can implement in devpi a concept similar to travis build<br>
> >> status<br>
> >> > imagens, which we could then use in the plugins_index page.<br>
> >> ><br>
> >> > Against python 2.6 the script is failing, I have yet to investigate.<br>
> >> ><br>
> >> > great, i am travelling to Pycon DE tomorrow morning but should be online<br>
> >> > > from time to time.<br>
> >> > ><br>
> >> ><br>
> >> > Nice tripe and good PyCon!<br>
> >><br>
> >> Thanks! Got back but caught a flue ...<br>
> >><br>
> >> cheers,<br>
> >> holger<br>
> >><br>
> ><br>
> ><br>
</div></div></blockquote></div><br></div></div>