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