<br><div>does this fairly represent the policy : buildout removes all files installed by parts anytime the top parts/develop/egg section changes because "paranoid is safer".</div><div><br></div><div>I can imagine there would be problems, especially when parts depend on other parts. (checking versions etc)</div>
<div><br><br><div class="gmail_quote">On Thu, Sep 2, 2010 at 5:48 PM, Jim Fulton <span dir="ltr"><<a href="mailto:jim@zope.com">jim@zope.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br></div></div>
Buildout provides a default policy of removing installed files and<br>
directories *reported by the install method*. I think this is a<br>
reasonable default policy. It also allows a part to be uninstalled<br>
even if the original recipe code is unavalable for some reason.<br></blockquote><div><br></div><div>Right, and I've run into that. but actually at that time I had renamed a </div><div>develop egg and the buildout failed because the original was missing.</div>
<div><br></div><div>maybe it works for parts but not for develop ?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
A recipe author can completely replace this default policy by:<br>
<br>
- Not reporting any installed files in the install method of an<br>
install recipe, and by<br>
<br>
- providing an uninstall recipe (entry point) that does whatever<br>
uninstall logic seems desireable.<br></blockquote><div><br></div><div>this would work, but it would be a hack and would be a problem when it really </div><div>does need to get uninstalled.</div><div><br></div><div>but I've got a brighter idea: rather than shutil.copy the whole of django in each time,</div>
<div>just do a symlink from the download cache.</div><div><br></div><div>safe and quick to remove and install</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
As an aside, wrt production deployment:<br>
<br>
- We use buildouts to build rpms used to deploy software. Deploying via a<br>
binary RPM (or a deb or whatever) </blockquote><div><br></div><div>oooh... <br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- We use buildouts to install/update configuration files independent of<br>
software. <br>
The recipes needed by this are installed as part of the software<br>
RPM,</blockquote><div><br></div><div>nice, I get it now</div><div><br></div><div><br></div><div>does the second buildout get run by the RPM's post-install scripts ? </div><div><br></div><div>or do you just install it, then run the config-file buildouts ? </div>
<div><br></div><div>I don't know much about rpm</div><div><br></div><div><div><br class="Apple-interchange-newline">I've had blow ups when something went wrong using just buildout and then there isn't a safe way to back out.</div>
<div>tried to add lxml the other day and it failed to build.</div><div><br></div><div>so this is definitely a solution for that.</div><div><br></div><div><br></div></div><div>-felix</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Jim<br>
<br>
--<br>
<font color="#888888">Jim Fulton<br>
</font></blockquote></div><div title="signature"> </div><br></div>