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.
Regards,
David
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
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
