[pytest-dev] plugin status page

[holger krekel]

Hi Bruno,

On Thu, Oct 24, 2013 at 13:01 -0200, Bruno Oliveira wrote:
> Hi Holger,
> 
> On Thu, Oct 24, 2013 at 11:58 AM, holger krekel <holger at merlinux.eu> wrote:
> 
> > OK.  I think you can leave "--use-mirrors" away, btw.
> >
> 
> I usually pass that parameter as is recommended by Travis' docs:
> 
> "We highly recommend using --use-mirrors if you override dependency
> installation command to reduce the load on PyPI and possibility of
> installation failures."
> 
> (from:
> http://about.travis-ci.org/docs/user/languages/python/#Travis-CI-uses-pip)
> 
> Any reason to remove it that I'm not aware of?

a) official mirrorrs are deprecated, see https://pypi.python.org/mirrors
b) PyPI simple pages and release files are served through a CDN

> > Perfect, that would greatly simplify things. Let me know if there is
> > > anything I can do to help.
> >
> > I just implemented it:
> >
> >
> > https://bitbucket.org/hpk42/devpi/commits/3a8ff0503599358deeefedc581e88c03c4b94ae3
> >
> > However, it's maybe not exactly what we need.  "devpi test PKG" works by
> > looking up the newest PKG release on the index, downloading and unpacking
> > it and then running tox.  Passing "devpi test -c tox.ini" will always
> > prefer the external tox.ini, though.  We could maybe add a second option
> > "--fallback-ini" option that only is used if there is no tox.ini in the
> > downloaded package.
> >
> 
> I guess we could execute that as a two step process, asking for devpi to
> download the package first to inspect if it has a tox.ini file, and change
> "devpi test" command line accordingly... but if you think implementing a
> "--fallback-ini" option is easy/useful for others, that's even better.

I want to release devpi-1.2 any day now.  Adding --fallback-ini as
an experimental option is ok, i guess.  Once we are through the testing
plugin experience we can think about refining it.  But others might
want to use similar techniques (e.g. Pyramid plugins etc.).
So i am going to add the fallback option probably tomorrow.

> Note that to play with the devpi-{client,server} current trunk you can do:
> >
> >     pip install --pre -i https://devpi.net/hpk/dev/+simple/ -U devpi
> >
> > and then run your own devpi-server similar to:
> >
> >     http://doc.devpi.net/latest/quickstart-releaseprocess.html
> >
> > And especially try "devpi list PKG" after "devpi test PKG" to see
> > test results.
> >
> 
> Yes, have been playing around with it, very cool. :)
> 
> 
> > > 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.
> > >
> > > But I guess this is too specific to pytest...
> >
> > Hum, some badge makes sense.  Not sure which, though :)
> >
> 
> I was thinking that a "pytest compatible" badge is too specific for a
> generic tool like devpi, don't you think?
> 
> Creating an app on Heroku to store test results from the travis jobs and
> serving appropriate badges seems simple enough... is this a direction you
> think we should take?

Might make sense.  OTOH test results are already stored with devpi
so at least it makes sense to try to use that information.  Might
need a bit of web API tweeks to make usage convenient.

best,
holger


> 
> Cheers,
> Bruno.
> 
> holger
> >
> > >
> > > Cheers,
> > > Bruno.
> > >
> > >
> > > >
> > > > best,
> > > > holger
> > > >
> > > > > Cheers,
> > > > > Bruno.
> > > > >
> > > > >
> > > > > > I found the reason for that (http vs https) and now the job runs
> > > > against
> > > > > > Python 2.6, 2.7, 3.2 and 3.2.
> > > > > >
> > > > > > Thanks!  Got back but caught a flue ...
> > > > > >>
> > > > > >
> > > > > > It happens, hope you get better soon. :)
> > > > > >
> > > > > > Cheers,
> > > > > > Bruno.
> > > > > >
> > > > > >
> > > > > > On Sun, Oct 20, 2013 at 3:52 AM, holger krekel <holger at merlinux.eu
> > >
> > > > wrote:
> > > > > >
> > > > > >> On Mon, Oct 14, 2013 at 23:52 -0300, Bruno Oliveira wrote:
> > > > > >> > > > >
> > > > > >> > > > > - i'd collapse NAME and VERSION columns to save space,
> > i.e.
> > > > > >> > > > >   "pytest-bdd-0.6.1".
> > > > > >> > > > >
> > > > > >> > > > > - 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
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >> > Done, opened a PR for discussion and reviewing. :)
> > > > > >>
> > > > > >> only got to it now, looks good so far!
> > > > > >>
> > > > > >> > > > > - 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.
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > > > May I ask why we would need the repository locations? I
> > mean, to
> > > > > >> work on
> > > > > >> > > > the compatibility feature we can work directly with
> > packages in
> > > > > >> pypi or
> > > > > >> > > > devpi...
> > > > > >> > >
> > > > > >> > > purely for the person reading the page and wanting to look at
> > the
> > > > code
> > > > > >> > > or do a PR.
> > > > > >> > >
> > > > > >> >
> > > > > >> > Oh I see! Well, parsing the urls seems problematic, because we
> > also
> > > > > >> have to
> > > > > >> > take in account the username ("hpk42/pytest" for example). I
> > looked
> > > > at
> > > > > >> the
> > > > > >> > GitHub and BitBucket's rest APIs to see if we could use them for
> > > > > >> searching,
> > > > > >> > but it seems only GitHub at the moment has a search API (and in
> > beta
> > > > > >> stage
> > > > > >> > at that).
> > > > > >> >
> > > > > >> > I think we will have to maintain the repository list manually.
> > > > Package
> > > > > >> > authors can help as well by simply opening PRs adding
> > repositories
> > > > for
> > > > > >> > their plugins I guess.
> > > > > >>
> > > > > >> What about generating a "plugin details " page for each plugin so
> > we
> > > > don't
> > > > > >> have to think too hard about what to put in the index page?
> > > > > >>
> > > > > >> > > A very interesting bit will be the "2.4.2 compat" and "dev"
> > compat
> > > > > >> > > > <snip>
> > > > > >> > >
> > > > > >> >
> > > > > >> > Some late night quick hacking and I have come up with this
> > proof of
> > > > > >> concept:
> > > > > >> >
> > > > > >> > https://www.travis-ci.org/nicoddemus/pytest-plugs
> > > > > >> >
> > > > > >> > As it is right now it serves only as a prove of concept, of
> > course.
> > > > The
> > > > > >> > idea is using travis to handle running things for us, driving it
> > > > using a
> > > > > >> > script that downloads and run tests using tox. We can then
> > collect
> > > > json
> > > > > >> > information from that and POST those results back to devpi.
> > Also we
> > > > can
> > > > > >> use
> > > > > >> > its build matrix to test against different pytest versions, for
> > > > example.
> > > > > >>
> > > > > >> Hum, interesting.  Is this mainly to make use of travis-ci's build
> > > > hosts?
> > > > > >> What is the advantage over just invoking "devpi test PLUGIN-NAME"
> > > > from the
> > > > > >> script to automate the download/unpack/test/post-results steps?
> > > > > >>
> > > > > >> > I guess we can implement in devpi a concept similar to travis
> > build
> > > > > >> status
> > > > > >> > imagens, which we could then use in the plugins_index page.
> > > > > >> >
> > > > > >> > Against python 2.6 the script is failing, I have yet to
> > investigate.
> > > > > >> >
> > > > > >> > great, i am travelling to Pycon DE tomorrow morning but should
> > be
> > > > online
> > > > > >> > >  from time to time.
> > > > > >> > >
> > > > > >> >
> > > > > >> > Nice tripe and good PyCon!
> > > > > >>
> > > > > >> Thanks!  Got back but caught a flue ...
> > > > > >>
> > > > > >> cheers,
> > > > > >> holger
> > > > > >>
> > > > > >
> > > > > >
> > > >
> >