On Wed, 2009-07-22 at 13:03 +0200, holger krekel wrote:
> 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.
ok, lets make a small resume about my tasks
1. a hook for turning a txspec to a gateway
2. a nice hook for taking options and generating a set of txspecs
(the default being just to pass along the ones from options)
3. a virtualenv plugin
a. support for setting up a virtualenv
with a custom python version + versions of packages
b. support for executing the virtualenv setup via networked gateways
ie the socket one and the ssh one
regards
Ronny
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
