On Dec 21, 2007, at 10:18 AM, David Pratt wrote:

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.


IMO, it is much more practical to create a clean system package for Python. By a clean system package, I mean one that is equivalent to buildoing from source and has nothing added. This is equivalent to what you would build yourself but makes deployment much easier because you don't have to rebuild Python every time you make a new release. You can use this in development as well.

Jim

--
Jim Fulton
Zope Corporation


_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to