[py-dev] hook ideas for better use/abuse of txspecs and distribution

[Ronny Pfannschmidt]

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