bzr-packagers team mailing list archive

[Ian Clatworthy <ian.clatworthy@xxxxxxxxxxxxx>]

On 31/03/10 13:31, Sidnei da Silva wrote:
> On Tue, Mar 30, 2010 at 10:06 PM, Ian Clatworthy
> <ian.clatworthy@xxxxxxxxxxxxx>  wrote:
> > Hi Sidnei and other buildout gurus,

> Ok. I will try to give the 10.000 feet level overview.

> Basically buildout itself doesn't do much, other than providing some
> infrastructure around easy_install, for downloading eggs, and doing
> stuff with recipes. All the useful stuff is done by recipes.

> It compares the
> current configuration (as specified in buildout.cfg) with whatever is
> in .installed.cfg to detect if some configuration changed. If so, it
> will call the 'uninstall' entry point to remove what might have been
> installed by the previous invocation, so that it can then call
> 'install' with a (supposedly) clean environment.

> This is where things start to get tricky. As you might have guessed,
> your experience will only be as good with buildout as the recipes you
> are using. Recipes are free to have a noop 'uninstall' for example,
> which many do. This can be good or bad, depending on what you want to
> do.

Thanks a heap. That nicely explains why things are behaving as they are.

> there might be an option provided by the recipe itself to disable this
> behavior (or we could add one, I have commit rights).

> It sounds like you do not want the recipe to uninstall anything, ever,
> instead relying on manually deleting directories that might be on the
> way. If that's what you want it to do, we can make it do it.

Yes, I think that would help a lot. I think we want to be able to 
configure the bzr-related recipe so that it skips uninstalls altogether. 
Maybe we still want to uninstall included parts so we can reinstall 
them? Not 100% sure. We certainly want to leave non-included parts 
previously installed completely as they are though.

> Although, from your description of the problem, it seems like your
> problem is actually that you have 2 different buildout.cfg files and
> you are running buildout on the same directory, each time with a
> different configuration file.

Right. I can imagine one day wanting to build 4 installers: 2.0, 2.1, 
2.2 and trunk. To save space and time, I'd like to get to the point 
where each bzr part was a shared repository and each "build" was a 
branch within that. So reusing the one scratch area for multiple 
installer builds is certainly highly desirable long term IMO.

> I'm happy to answer more questions. I'm writing mostly from memory
> here so one or other fact might not be completely accurate.

Another thing I'm curious about is what changes are required to run the 
buildout part of the windows build scripts on Ubuntu? (It's far easier 
for me to develop on my home machine that on our installer build VM.) 
It's all Python now so it ought to be possible but it always locks up 
for me. Maybe the bootstrap stuff is Windows-specific and we need to 
switch in GNU/Linux bootstrap code if we're running on that platform? To 
see what I mean, try this:

1. Grab lp:bzr-windows-installers
2. Run "build.py parts"
3. Watch it start then seem to hang waiting on ... who knows what. :-(

That curiosity aside, I think the next step is to improve the 
gf.recipe.bzr recipe so that we can drive it in the way outlined above. 
How long do you think that will take? Do you have some time to help make 
the required changes? (If not, I'll add it to my list and get back to 
you when I find some time to tackle it.)

Thanks for your help,
Ian C.