On Wed, 2003-06-18 at 20:07, Adrian van den Dries wrote: > Agreed; we can have a separate zopectl package that is dedicated to > managing instances.
I'm hopeful that Luca agrees. > > I'd advise against installing Zope library files into site-packages > > unless you put them in a site-packages subdirectory (like > > site-packages/zope270 or site-packages/zope271). Otherwise there will > > be no way to run multiple Zope versions on the same machine sanely > > because different Zope versions have different libraries. > > May I respectfully ask why there is so much concern with such > complicated setups? Surely a production environment (which is what > any Zope distribution should aim for) will standardise on a software > version? It's often the case that you want to upgrade to a new Zope (or Python) version on a machine and it's desirable that you be able to run both the older version and the newer version on the same machine during the cutover. For this reason (and others), during production rollouts Zope Corporation actually never uses the system-installed Python on a machine nor does it use binary-packaged Zope distributions. Instead, we install a whole separate tree (typically inside of /home/zope) using CVS and various source buildouts that looks like this: bin/ (control scripts) opt/ (software like Zope, Python, Apache, Zope products, etc.) var/ | |--zope/ (zope instance and data files) | |--apache/ (apache instance and data files) We have make-driven software that creates us a tree via a single command by checking out various version of Python, Zope, etc. from CVS and compiling and installing them. Different versions of Zope and Python, etc. can be installed in opt and we use symlinks to manage versioning. We never install any Zope-related files to a particular Python's site-package directory (even the Pythons we install ourselves) because we like the flexibility of being able to use any Python version we like without needing to copy Zope library files over between Python site-package directories. We just use the stock Zope software home blob and munge the PYTHONPATH as necessary. This works out pretty well in practice because we never have any dependency on any system installed software besides C libraries, CVS, make, and the shell. This makes it easy to deploy Zope to many (possibly divergent) systems without thinking too hard about system incompatibilities and what's installed in a particular Python's site-packages directory. > If the concern is because *developers* want to run multiple Zope > instances on multiple Zope versions with multiple Python versions, > then I would suggest writing an *alternative* mechanism for developers > to mangle their PYTHONPATHs and whatever. It does benefit developers, but I don't think it's solely for the benefit of developers. It seems that most large systems install themselves this way; for instance you can install multiple Apache versions on a single system without regard for them stomping on one another. Same for MySQL, Postgres, etc. It seems to be a fairly common pattern. The fact that we depend on Python doesn't seem to make much of a difference from the perspective of someone installing Zope. If Apache depended on Perl, wouldn't necessarily expect my Apache to stop working because I deleted some files from my Perl library directory. > > That said, if you always manage upgrades via your package > > distribution mechanism, and you only allowed one version of Zope to > > be package-installed on the machine at once, perhaps putting the > > files in site-packages wouldn't be such a big deal. > > This is doubtless the most common scenario (or it should be). It is when things go right, but when they go wrong, it's fairly limiting to only be able to have a single version of Zope installed on your system. That said, it's really a packaging decision. I'm currently most concerned about making Zope to be easy to install from source. If I can add features to the source install to make it easy for binary packagers to package Zope, I'll do so, but I won't limit the source installer to installing to a single predeclared place. The current Zope source tarball install will continue to allow you to install multiple Zope software homes on your system without regard to the Python you use to invoke them. The binary packaging scheme for a particular distribution is up to the packager. We can probably provide support in the setup.py file for installing libraries to site-packages to help binary distributions do so if they choose. I don't think it's a particularly good idea, but I'm not in charge of those distributions either, so my opinion shouldn't count for much. ;-) > > I'm afraid you're going to need to change a lot of things to support > > Zope 2.7. Please let me know if I can help. > > Should we move this to debian-python? Just tell me where to go and I'll go there. ;-) > > Servicing the many goals of installation and configuration is very > > difficult, but I'm pretty confident we can make your life a little > > easier in the long term given that I understand your requirements. It > > will also make Zope that much more "debian-friendly" in the long run. > > As long as we can distinguish those parts of this exercise that will > apply to the Zope distribution from those that should be specific to > Debian's package, this shouldn't be too hard. > Yup. Thanks for the input! - C _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )