W dniu 15.06.2011 20:30, Paul Larson pisze:
So having those requirements my goals were to build a tool that would be useful for those two tasks:
- Daily development helper as a sort of CI tool.
- Monthly release helper
So for purpose 1, if we wanted to use the same tool to make this easy,
could we just do something like 'lava-ci project develop'?
I was writing it this morning. It actually pulls all of the branches that compose lava and gives you an ability to install them in a managed virtualenv instance.
It seems to me, that on some things, this could be overkill, or not really make it that much simpler. For instance... in the case of lava-test you may want to also install python-apt, but there are other things like usbutils. In the case of the dispatcher, it can also run completely from the source branch.
So there are three possible cases:
1) A component has no dependencies and runs from tree (awesome!) 2) A component depends on something we make 3) A component depends on something others make
Only case 1) is easy to work with. Virtually everything has some dependencies that either differ from one release to another (like python-simplejson incompatibility I ran into when testing on natty some months ago) or have more rich interface on the more recent version (and then it fails to work on lucid). For the rest we need to be able to reliably setup what is required to use and develop our code.
Except there are things like conmux that you would want to install, and configure to tell it how to get to your test machines. For situations like those, unless you have already thought of it here, I think it's no harder to just provide instructions for creating a development environment.
Instructions fail. Reproducible code works.
Reproducible code is also dog-fooding our instructions in practice.
However I'm well aware that other projects such as those dependent on the libraries you mention, and the lava-server piece can be somewhat trickier. How much of a stretch is it to extend this to cover case 1 as you mention, or do you feel for all of these it would be easier to provide a script in-tree to setup virtualenv + instructions for configuration to setup a development environment?
I think this is the core feature required for development and since so much information is already there extending it to support development is a natural consequence.
I will post updates later this evening. I added one new command tree that makes this possible.
Thanks ZK