On Wed, 2003-06-18 at 13:18, Luca - De Whiskey's - De Vitis wrote:
On Wed, Jun 18, 2003 at 11:23:15AM -0400, Chris McDonough wrote:
Actually the scripts in $INSTANCE/bin aren't shell wrappers for things in $PREFIX/bin, they're shell wrappers for thing in $PREFIX/lib/python/Zope/Startup. But yes, they are shell wrappers.
And so they would be copied for all instance installed: they would not probably be that large, but what about symbolik links?
These files needn't be here really. There are two scripts: zopectl and runzope. They are convenience shell scripts that run zopectl.py or runzope.py scripts that live in a software home after setting certain envvars. Each of these shell scripts identifies a unique combination of software home, instance home, config file path, and pythonpath. These can be unique per instance, so using a symlink to a common set of files will not work. A typical zopectl script could be replaced with the following command line: ZOPE_HOME=/opt/Zope27 \ INSTANCE_HOME=/usr/local/zope/instance1 \ PYTHONPATH=/opt/Zope27/lib/python \ /usr/bin/python2.2 \ /opt/Zope27/lib/python/Zope/startup/zopectl.py \ -C /usr/local/zope/instance1/etc/zope.conf The -C tells where the Zope config file is. The config file represents settings for a single Zope instance. One of these config files is created for each Zope instance via 'mkzopeinstance'.
If you made a global control script that worked as per your example, how would you identify where the 'default' instance is?
I was not aware of a zopectl in the repository so i builded one in python for Debian. As i can see it's quite more powerful than the one you are going to include: http://packages.debian.org/unstable/admin/zopectl.html I would care about any comment.
I think this is great. The zopectl that ships with Zope now is capable of controlling a single Zope instance. Your system takes on the larger burden of simultaneous multi-instance Zope configuration and control on a single machine. Your code looks quite nice as well. Your system is a perfect example of a value-added frontend for zope. I can see that many people would want to use this kind of framework. I'd love to see people come up with their own Zope mgmt frameworks and use them as a frontend for Zope instance management with minimal involvement from the Zope source tarball installer. Different frameworks will be more or less valuable on different platforms; for example a Windows multi-instance controller might be a GUI app. As far as the current installation regime goes, I'm aiming to keep common-case (single-instance) installation and operation very simple, much like Apache's. If you want to change your Zope controller to work with 2.7, I think you'll either be very happy (or very disappointed, seeing how much work you put in to creating your own config files) to know that Zope 2.7+ instances have their own configuration file which has a syntax patterned after an Apache configuration file; the parsing system uses the ZConfig package (http://www.zope.org/Members/fdrake/zconfig/). I have attached the zope.conf.in file that represents a valid Zope instance configuration file. As an upshot, z2.py no longer exists and the "zopectl" that runs Zope now on the HEAD knows how to read and interpret the config file. All of the settings you've made configurable within, e.g. your 'default.conf' are configurable via this config file. Additionally, ZConfig lets you perform a textual include of external files into a config file; if you've got common settings in one config file, you can customize the settings for an instance in a small instance config file and %include the common config file into it (even via an HTTP GET if necessary). See the zconfig docs for more information. I'd love to see your zopectl system work with Zope 2.7, and though I likely wouldn't want to package it with Zope, I'd love to see it be able to operate as a front end controller for multiple Zope 2.7 instances. It will not work against the current Zope HEAD because the HEAD no longer has z2.py (everything about Zope startup has changed post-2.6). If you want it to support Zope 2.7, I'd be happy to answer any questions about the new installation/startup process. In particular, I think you'd need to change your zopectl conf file. Instead of keeping all configuration options in the zopectl.conf file, each instance section could keep a smaller set of keys. For example: [Zope] Config-File: /path/to/instance/etc/zope.conf [Instance2] Config-File: /path/to/instance2/etc/zope.conf .. etc... The instance config files could %include a common /etc/zope.conf config file with most of the default settings (instead of using a [DEFAULT] section). You could then throw away most of your parsing code in ZopeCTL.py, and instead of running z2.py in your __start method, run the zopectl associated with the software home, pointing it at the proper config file.
FWIW, I'd be very opposed to any sort of limitations on where instance homes could be placed to service this global control script's need to find instances. [...] http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration dated Aug 22, 2002 8:09 pm for more background.
It's my opinion that a zope instance can be described trough a configuration file, thus not requiring multiple commands or links but rather a single command capable of using multiple configuration files. If you combine my zopectl script with the patch is proposed for z2.py (http://collector.zope.org/Zope/925), you'll have a good FHS[1] compliant framework for multiple INSTANCE_HOMEs (being still able to place any file where you like).
z2.py is gone in 2.7, alas. But the pidfile location is configurable in Zope 2.7 within the zope.conf file on a per-instance basis (via the pid-filename directive), so this becomes pretty trivial.
This sounds good. I'm not so sure about $SKELPREFIX. Maybe we could [...] libraries in the lib directory). This is why they're currently not broken apart.
To say it all there is only one thing i really need: a way to install _all_ documentation files under a separate directory in a way thay cannot overlap. For what concern Debian, the intallation home will still be /usr/lib/zope untill python fully comply FHS[1] (http://python.org/sf/588756). I'll probably move it to /usr/lib/python2.1/site-packages in future, but i'm still not sure.
Support for installing docs to a specific directory is no big deal. I'll add it to the Zope 2.7 TODO. I'm not sure what the Python FHS-noncompliance bug has to do with Zope. If you're worried about .pyc/.pyo bytecode file generation in a nonwritable directory, I wouldn't because the current Zope 2.7 installer compiles bytecode upon install (thus during runtime it will never attempt to compile any bytecode at Zope startup time). 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. And if you install into site-packages/zopeXXX, it's not much different than just installing them into a completely Python-independent directory like /usr/lib/zope because you'd still have to put that directory on the PYTHONPATH. 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.
In the past, my offers to provide upstream support for Debian packaging hasn't been met with much enthusiasm. If I can make it easier for people to package Zope for Debian, I'd love to, but I'd need to have some buyin and support from the current Debian packagers. Otherwise, it ends up being a waste of time on both of our parts as it won't be what's best for either of us.
It's not that easy to co-maintain the Debian package for Zope: we actually lacks the structures to set up work with non Debian Developers. I suppose this problem will be solved soon, but if you like i can start collecting patches for the CVS repository i've already set up for that purpose. Take a look at https://alioth.debian.org/projects/pkg-zope and its CVS repository.
Thank you, I have. 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.
Debian's packaging and installation strategy for Zope has always been very customized and divergent from the Zope source distribution's packaging and installation strategy. At very worst, it could stay this way.
Debian has choosed to be be strictly compliant to FHS[1], including it in the Debian Packaing Policy. Not complying to Debian Policy is considered a grave bug for any package in the distribution. Current Zope upstream package is not that compliant, so we always have to modify the package. I hope this will change in future.
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. If you can provide specific direction on how to make the Zope source tarball installer service your goals better, I'll be happy to try to implement any suggestions given that it makes sense in the larger cross-platform context. Thanks! - C