Hi Holger, On Thu, Oct 24, 2013 at 11:58 AM, holger krekel <[email protected]> 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? > 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. 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? 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 <[email protected] > > > > > 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 > > > > >> > > > > > > > > > > > > > >
_______________________________________________ Pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
