On Wed, Jul 22, 2009 at 12:33 +0200, Ronny Pfannschmidt wrote:
> > In the --tx specifciation one could say e.g.
> >
> > popen//python=python2.5//virtualenv=docutils-0.5,mercurial-1.2
> >
> > and a pytest_virtualenv plugin could take it, call virtualenv
> > and eventually start up a gateway with the venv/bin/python.
>
> ok, how would i generate sets of txspec declarations,
> cause i want to combine multiple arguments in order to generate the python
> versions and the package versions
i guess by implementing a ``pytest_configure(config)`` hook to
add a few txspecs. We need to extend the API to the
config object for that, currently it's readonly. Maybe:
def pytest_configure(config):
# access your custom plugin options to
# determine which combis to generate
config.setvalue('tx', ['spec1', 'spec2', ...])
> > > howevers users should be free to generate own gateways to custom set up
> > > things like virtualenvs on local or remote computers and be able to
> > > combine txspecs with own options
> >
> > To get started, i would first try to get things working with
> > popen, then extend to handle remote places - would you want
> > to automatically install virtualenv there and/or require
> > setuptools, btw?
i presume it makes sense to you to first try popen.
> > > 2. pytest_select_gateways(test, list of gateways) -> list of gateways
> > >
> > > this hook is supposed to select the gateways each test is supposed to
> > > run on
> >
> > something like this could make sense. It's a second step, i'd think,
> > though.
> i would certainly need it
> for example tests for mercurial would hardly work in a virtualenv thats
> only only set up for bazaar
you could still skip the tests late-bound but i can see you want
to avoid even trying tests in unfitting environments.
The issue here is to have a somewhat higher level API for
what you call "list of gateways" because the raw low-level
execnet-gateways are not fitting. you rather want something
where you have structured access to the "test nodes", their
txspecs etc. and this requires a bit of refactoring.
> > Can you imagine working on a branch to try implement these hooks?
> > I am willing to help/review.
> sure
fine. please add a bitbucket diff-email
service to py-...@codespeak.net then.
best,
holger
> >
> >
> > > the default implementation should pass a test to all of them or
> > > distribute them reasonable
> > > the api for this one probably needs a few more idea since i think my
> > > initial proposal is not adequate for all uses
> >
> > yes, working from concrete uses (a pytest_virtualenv
> > plugin) makes sense.
> >
>
>
--
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
