On 27 Oct 2005, at 08:58, Dario Lopez-Kästen wrote:
well, on larger shops like ours, the sysadms always want to know why we introduce Yet Another Non-Standard Component to the system setup that cannot be RPM'ed like the rest. And I am not talking across pythoin versions, but oin the same release series (ie. 2.3, etc)

I know it is more convenient to self.compile() the python, but it is always hard to argue with the sysadms on this issue. Our current solution is to provide a precomipiled rpm with the pythons we want to use.

Why is that the standard os-distributed pythons do not work with zope? They seem to work with other python sw...

For the Zope setups the pattern that I have seen most often in larger shops is buildout scripts that create self-contained full instances with Python, Zope and the instance home. These are easy to set up and update with one simple buildout script or Makefile or whatever strikes your fancy. This is exactly the same level of "convenience" (and maintainability) as saying "rpm -Uvh foo.rpm". Obviously this self-contained ZEO client with its own Python could be done as a RPM or set of RPMs as well.

The main idea is that you isolate Zope and Python from the rest of the system. You can then use simple auto-upgrading schemes like yum or even the redhat network to keep everything up to date, while never running the risk of influencing or bringing down Zope by making unforeseen changes to the Python in use, as could happen with the system Python. The same is true for any add-ons you might install into the Python used for Zope.


Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to