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.
jens
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
