Hi Benji. This is exactly what I have been doing up till now and has been working well for quick work on a local development machine. My current thinking though is to take control of as much of the software as possible so that development == deployment on my local machine to mitigate the risk of breaking things even if it means more disk. I am doing this in conjunction with stripping the deployment server to it's barest bones and bringing as much of the software into the buildout as possible.

I really would like to see a two stage buildout that does the python construction with a python.cfg and then the main buildout with buildout.cfg file as part of the standard fare. I'm trying a few things today to see if a simple event class and callback can be used to create the python first and have the callback's handler run the main buildout as an experiment.


Benji York wrote:
Darryl Cousins wrote:
I'm trying to created an isolated environment using buildout. I had
understood that defining a custom build python would ensure that all
eggs are installed and compiled with the custom python.

An alternative to building Python with buildout is to build a single "clean" Python and use it for all their buildouts.

Some advantages of this approach are that your buildouts take less time to build from scratch (no building Python every time), and are a bit smaller (by about 115MB on my system). I keep lots of buildouts around (a few dozen), so those advantages add up.

Of course it also lets you stay away from the generally "dirty" system Python (just as the Python-per-buildout strategy does as well).
Zope3-users mailing list

Reply via email to