Proposed installation changes for review
Hi folks, An effort to improve Zope 2 installation, startup, and configuration for Zope 2.7 has been ongoing for some time now (see http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration). The effort has reached a point where we believe it is reasonable to merge its fruits to the Zope trunk. Before doing so, however, we want to gather input from people who care deeply about Zope configuration and installation; particularly those who have significant investments in the existing behaviors of Zope 2 configuration and installation. A bunch of stuff is changed (most notably Zope no longer uses environment variables as configuration, and instead defers to command-line arguments and config file values). What follows is a summary of changes, a walk-through of a Zope 2 installation under this regime, and a list of the configuration-file changeable parameters exposed by the current Zope configuration schema. Please provide your feedback before this Friday, March 14. If possible, check out and try the new software. If there are showstopper issues for a lot of people, we will consider not performing the merge directly after that date. Otherwise, the merge will be performed at any time after the 14th. Thanks! - C ----- Major changes in Zope 2.7 ========================= Zope 2.7 will contain a number of changes related to the build process and configuration. The scripts used to start Zope will also be substantially changed. The implementation of these changes is not yet complete, but a substantial portion has been done and is expected to be merged into the Zope 2 trunk in the near future. The exact schedule for merging these changes has not been determined; additional notice will be provided. These changes are substantially based on efforts by Chris McDonough on the "chrism-install-branch". Major changes ------------- The following are the most important and user-visible changes compared to Zope 2.6 and the current CVS HEAD: - Configuration is normally done by editing a config file instead of passing command line options. The configuration file is handled by the ZConfig package. - Environment variables are no longer used for configuration. - Building and installing the software have become more clearly distinct; the installation can be separate from the build. - Zope 2.7 uses the "instance home" model in the normal case: a script in the installed software is used to create new "instances" of Zope. Each instance is defined by a directory tree containing configuration, scripts, and data. (For convenience, the instance and the installation can be located in the same directory, and the build area may be used in lieu of an installation if desired.) - The z2.py, start, and stop scripts have been replaced by the runzope and zopectl scripts. - The runzope/zopectl scripts do not accept the same command-line arguments as z2.py used to accept. - The wo_pcgi.py script used to build Zope without PCGI support has been replaced by the common Unix build sequence of configure, make. - The pcgi/ directory and the w_pcgi.py script have been removed from the top of the source tree. The pcgi/ directory may be made available as a separate distribution. (The application server still has support to allow connections from a PCGI-capable Web server.) - The ZServer package has been moved from the top of the source tree into the lib/python/ directory. Getting the code today ---------------------- The implementation lives in the "new-install-branch", which is a "partial" branch rather than a complete branch: only the files and directories which need to be changed have been placed on the branch; all other files are used from the CVS HEAD. The current state of this code can be checked out from CVS using the command: cvs -d :pserver:anonymous@cvs.zope.org:/cvs-repository co \ -r new-install-branch -f Zope The installation instructions in doc/INSTALL.txt has been updated on the branch; that file provides detailed information on creating an installation and instance. (A copy has been attached for convenience.) A sample installation/startup runthrough --------------------------------------- The below is the output from a sample install session. During this session, we install the Zope software to /tmp/zopehome and install an instance home to /tmp/insthome. [chrism@james software]$ cd NewInstallBranch/ [chrism@james NewInstallBranch]$ ./configure --prefix=/tmp/zopehome Configuring Zope installation Testing for an acceptable Python interpreter... Python version 2.1.3 found at /home/chrism/bin/python Python version 2.1.3 found at /home/chrism/bin/python2.1 Python version 2.2.2 found at /home/chrism/bin/python2.2 The optimimum Python version (2.2.2) was found at /home/chrism/bin/python2.2. - Zope top-level binary directory will be /tmp/zopehome. - Makefile written. Next, run make. [chrism@james NewInstallBranch]$ make "/home/chrism/bin/python2.2" inst/setup.py -q build_ext -i <... compilation output elided ...> Zope built. Next, do 'make install' (or 'make instance' to run a Zope instance directly from the build directory). [chrism@james NewInstallBranch]$ make install <... installation output elided ...> Zope binaries installed successfully. Now run '/tmp/zopehome/bin/mkzopeinstance' [chrism@james NewInstallBranch]$ /tmp/zopehome/bin/mkzopeinstance mkzopeinstance requires exactly one argument mkzopeinstance: Create a Zope instance home. usage: mkzopeinstance [options] directory Options: -h/--help -- print this help text -u/--user NAME:PASSWORD -- set the user name and password of the initial user [chrism@james NewInstallBranch]$ /tmp/zopehome/bin/mkzopeinstance \ --user=admin:123 /tmp/inst [chrism@james NewInstallBranch]$ cd /tmp/inst/ [chrism@james inst]$ ls bin etc Extensions import inituser log Products README.txt var [chrism@james inst]$ bin/zopectl start . daemon process started, pid=2947 [chrism@james inst]$ bin/zopectl stop . daemon process stopped Changing the configuration via the config file ---------------------------------------------- The Zope configuration file uses the ZConfig API and file format. See the ZConfig documentation PDF at http://cvs.zope.org/Packages/ZConfig/doc/zconfig.pdf for more information. The default Zope configuration file will live in the instance_home's /etc directory and will be named 'zope.conf'. The Zope configuration file allows you to change the following configuration variables: instance home client home debug mode effective user production installation (on/off) locale number of zserver threads the python "check interval" (thread switch timing) zserver read only mode pid file name lock file name structured text header level publisher profile file (debugging) cgi environment dns server (hostname resolving in logfiles) ip address (for zserver bindings) http realm automatic quotation of dtml request data security manager stack size security policy implementation (C, Python) skip authentication checking skip ownership checking max number of session objects session "add notify" script path session "delete notify" script path session timeout minutes access rule suppress site root suppression database quota size read only database zeo client name logging (access, event, debug, filenames, to syslog, etc). network servers (http, dav, ftp, monitor, etc) databases (storages, database classes, etc.)
A few questions / concerns listed below, otherwise it looks fine to me... On Mon, Mar 10, 2003 at 04:41:48PM -0500, Chris McDonough wrote:
debug mode
does this still toggle a whole bunch of things?
production installation (on/off)
what's this mean?
network servers (http, dav, ftp, monitor, etc)
is this where you set the ports? One thing I didn't see in your list is a way to extend the products path (currently I do that with $PRODUCTS_PATH). We need that. One more question: Does "zopectl.py" always detach from the terminal (booo) or not (yay) ? Or does it behave like z2.py and this depends on "debug mode" (booo) ? -- Paul Winkler http://www.slinkp.com
On Mon, 2003-03-10 at 18:07, Paul Winkler wrote:
A few questions / concerns listed below, otherwise it looks fine to me...
On Mon, Mar 10, 2003 at 04:41:48PM -0500, Chris McDonough wrote:
debug mode
does this still toggle a whole bunch of things?
Yes. It's still the case that nobody really knows what debug mode means. ;-) We just switched from only being able to specify the unknown via a command-line switch to being able to switch it from a config file and the command line.
production installation (on/off)
what's this mean?
Sorry, that should have been "product installation". This is the same as what the FORCE_PRODUCT_LOAD envvar does now.
network servers (http, dav, ftp, monitor, etc)
is this where you set the ports?
Yes.
One thing I didn't see in your list is a way to extend the products path (currently I do that with $PRODUCTS_PATH). We need that.
This wasn't documented in ENVIRONMENT.txt so it never made it in. Thanks for catching it.
One more question: Does "zopectl.py" always detach from the terminal (booo) or not (yay) ?
No. It can detach from the terminal, but it needn't. It is actually a mini shell. [chrism@james inst]$ bin/zopectl program: /tmp/inst/bin/runzope daemon manager not running zdctl> ? Documented commands (type help <topic>): ======================================== fg foreground help kill logreopen logtail quit reload restart shell show start status stop wait Undocumented commands: ====================== EOF zdctl> fg export EVENT_LOG_FILE EVENT_LOG_FILE= /tmp/inst/bin/runzope HTH, - C
On Mon, 2003-03-10 at 17:07, Paul Winkler wrote:
A few questions / concerns listed below, otherwise it looks fine to me...
On Mon, Mar 10, 2003 at 04:41:48PM -0500, Chris McDonough wrote:
debug mode
does this still toggle a whole bunch of things?
production installation (on/off)
what's this mean?
network servers (http, dav, ftp, monitor, etc)
is this where you set the ports?
One thing I didn't see in your list is a way to extend the products path (currently I do that with $PRODUCTS_PATH). We need that.
One more question: Does "zopectl.py" always detach from the terminal (booo) or not (yay) ? Or does it behave like z2.py and this depends on "debug mode" (booo) ?
Actually I like the way z2.py detaches or doesn't detach. Perhaps a separate config option would be good to control this. -- Edward Muller Interlix - President Web Hosting - PC Service & Support Custom Programming - Network Service & Support Phone: 417-862-0573 Cell: 417-844-2435 Fax: 417-862-0572 http://www.interlix.com
Edward Muller writes:
Actually I like the way z2.py detaches or doesn't detach. Perhaps a separate config option would be good to control this.
Detaching, or "daemonizing", will be a separate configuration parameter from everything else. The basic mechanism will be that provided by the zdctl.py/zdrun.py scripts in the zdaemon package. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Mon, Mar 10, 2003 at 10:31:13PM -0500, Fred L. Drake, Jr. wrote:
Detaching, or "daemonizing", will be a separate configuration parameter from everything else.
great, that is exactly what i really want. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's GARGANTUAN SKULL OF THE REVOLUTION! (random hero from isometric.spaceninja.com)
- Environment variables are no longer used for configuration.
I'll say it one more time. The roadmap[1] states under the "Simplifying the Zope experience" section: * simple tasks should be simple! Now, code required to extract a value from the environment: import os try: value = sanitize(os.environ.get("SOMETHING", default)) except Unsanitary: ...cope... # where 'sanitize' is in reference to any conversion procedures required # prior to the use of 'value' by program code Pretty simple. Enter ZConfig: $ du -sk ZConfig 374 ZConfig 374k of work devoted to replacing os.environ.get and its sanitizing code, and the result is a XML config file. I'm not saying this all for naught, but really, it should give you pause. Just how much have you really simplified configuration by doing this? Personally I think the problem of Zope's configuration hassles has been mis-identified. ZConfig cleans up and centralizes a maze of badly strewn out configuration code. It will extend the lifetime of the �ber-server concept ZServer employs. It does nothing to prevent the same mess from happening again, down the road. I believe a more lasting approach is to seperate the servers into small individual programs which only do 1 thing, and do it well. Then you combine those servers under a unified mangement framework, connect them together by using common communication idioms, the idea being--and follow me here, to use small programs combined together to provide a larger service. Sound familiar? -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer [1] http://dev.zope.org/Resources/ZopeRoadmap.html
On Mon, 2003-03-10 at 19:51, Jamie Heilman wrote:
- Environment variables are no longer used for configuration.
I'll say it one more time.
The roadmap[1] states under the "Simplifying the Zope experience" section:
* simple tasks should be simple!
Now, code required to extract a value from the environment:
import os try: value = sanitize(os.environ.get("SOMETHING", default)) except Unsanitary: ...cope...
# where 'sanitize' is in reference to any conversion procedures required # prior to the use of 'value' by program code
I'm sure you know this, but you are oversimplifying the situation. There are 41 (known) individual environment variables that control Zope's runtime configuration. Each use of an environment variable has its own parsing code, its own error-handling code and the actual code that does the work (ex: the session envvar parsing stuff in OFS/Application.py). If we take your example and make the error handling code "real" and the work code "real" we can estimate that it will consume about 1k. Multiply the number of bytes it contains with 41 and we can approximate about 41k of ad-hoc envvar handling code in Zope now. That's a boatload of largely untested and decentralized code, all of which is doing configuration. There is nothing simple about it. ;-)
Pretty simple. Enter ZConfig: $ du -sk ZConfig 374 ZConfig
374k of work devoted to replacing os.environ.get and its sanitizing code, and the result is a XML config file. I'm not saying this all for naught, but really, it should give you pause. Just how much have you really simplified configuration by doing this?
I couldn't really guess how much code in Zope is devoted to runtime configuration right now because it's spread over the entire codebase. I suspect you're right that it's not 374k. But for ZConfig only 116k is code, the rest is docs and tests: there are neither (to speak of, discounting the laughable ENVIRONMENT.txt) in the current 2.6/trunk codebase for configuration.
Personally I think the problem of Zope's configuration hassles has been mis-identified. ZConfig cleans up and centralizes a maze of badly strewn out configuration code. It will extend the lifetime of the Über-server concept ZServer employs. It does nothing to prevent the same mess from happening again, down the road.
Actually, it does. Packages may declare their own config schema type definitions and they may be included in the context of a larger configuration schema. This is demonstrated in the Zope schema in the new-install-branch in lib/python/Zope/Startup/zopeschema.xml: <schema prefix="Zope.Startup.datatypes" datatype=".root_config" handler="root_handler"> <!-- type definitions --> <import package="zLOG"/> <import package="ZODB"/> <import package="ZServer"/> .... We import the schema type definitions from the zLOG, ZODB, and ZServer packages here (these are named component.xml in each of these packages). The zope schema file uses these definitions to compose its own (type-checked) schema for a config file, and they can be (and will be) reused for ZEO and ZC's ZRS (Zope Replication Server). For Zope, ZServer is just another package that happens to define the schema type definitions for network servers.
I believe a more lasting approach is to seperate the servers into small individual programs which only do 1 thing, and do it well. Then you combine those servers under a unified mangement framework, connect them together by using common communication idioms, the idea being--and follow me here, to use small programs combined together to provide a larger service. Sound familiar?
I think this is done already. ZConfig is very general and very generic; you can configure just about anything with it and it has no Zope dependencies whatsoever. Fred Drake wrote it so it's pretty solid too. Before dismissing it out of hand, I'd encourage you to try it out. - C
Chris McDonough wrote:
Before dismissing it out of hand, I'd encourage you to try it out.
I'm not dismissing it, and I think you need to go back and read what I wrote again very very carefully without reading anything into it. I'm not trying to imply that using environment variables to configure the current codebase will reduce the code footprint. Even if it did, because of the distributed nature of the technique, its damnedly hard to maintain in a project as large as Zope. Also, I didn't say ZConfig was 374k of code, I said it was 374k of *work*. I chose that word very carefully, and obviously thats going to err on the side of conservatism as certainly the work was not isolated to that single directory tree. The point I'm trying to make is that Zope has learned nothing from the UNIX philosophy. Yes, you can extend the config schema. You can grow new, better config files, of extraordinary magnitude. The all-powerful server will grow from being all-powerful to being all-powerful + n. It will be able to read mail. Its heralds shall sit upon mountain high throwns hewn of the finest O'Reilly and New Riders scripture. But lo, still you won't be able to do something as mundane as limit the memory the FTP server is able to consume without affecting the HTTP server. Fracture the server infrastructure into small, seperate processes. The configuration of the individual pieces becomes trivial. The understanding of the overall data flow improves. When there's nothing left to remove from code, you've won. Some of the breaks have already been made, like the separation of the storage from its front-end. Thats good, we need more action along those lines. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
On Mon, 2003-03-10 at 21:42, Jamie Heilman wrote:
Chris McDonough wrote: The point I'm trying to make is that Zope has learned nothing from the UNIX philosophy. Yes, you can extend the config schema. You can grow new, better config files, of extraordinary magnitude. The all-powerful server will grow from being all-powerful to being all-powerful + n. It will be able to read mail. Its heralds shall sit upon mountain high throwns hewn of the finest O'Reilly and New Riders scripture. But lo, still you won't be able to do something as mundane as limit the memory the FTP server is able to consume without affecting the HTTP server.
Point taken.
Fracture the server infrastructure into small, seperate processes. The configuration of the individual pieces becomes trivial. The understanding of the overall data flow improves. When there's nothing left to remove from code, you've won. Some of the breaks have already been made, like the separation of the storage from its front-end. Thats good, we need more action along those lines.
I think this is a noble goal, but far beyond the scope of the current project, which is stated on the project page as "Make it easier for sysadmins and new Zope developers to install and configure Zope". I believe that ZConfig will help us towards this goal. It should also not hinder us from reaching the goal that you've defined above. Thanks, - C
The point I'm trying to make is that Zope has learned nothing from the UNIX philosophy. Yes, you can extend the config schema. You can grow new, better config files, of extraordinary magnitude. The all-powerful server will grow from being all-powerful to being all-powerful + n. It will be able to read mail. Its heralds shall sit upon mountain high throwns hewn of the finest O'Reilly and New Riders scripture. But lo, still you won't be able to do something as mundane as limit the memory the FTP server is able to consume without affecting the HTTP server.
Fracture the server infrastructure into small, seperate processes. The configuration of the individual pieces becomes trivial. The understanding of the overall data flow improves. When there's nothing left to remove from code, you've won. Some of the breaks have already been made, like the separation of the storage from its front-end. Thats good, we need more action along those lines.
You're barking up the wrong tree. Zope 2 won't change. Zope 3 is still in a state of flux, and that's where you should aim your speech. --Guido van Rossum (home page: http://www.python.org/~guido/)
But lo, still you won't be able to do something as mundane as limit the memory the FTP server is able to consume without affecting the HTTP server.
You can do this with Zope. Just use ZEO and run one ZEO front-end for HTTP and one for FTP. -- Steve Alexander
Steve Alexander wrote:
But lo, still you won't be able to do something as mundane as limit the memory the FTP server is able to consume without affecting the HTTP server.
You can do this with Zope. Just use ZEO and run one ZEO front-end for HTTP and one for FTP.
Sure, but then you carry along all the baggage of 2 zserver instances. Its a start, but there's still a ways to go. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
On March 10, Chris McDonough wrote:
Please provide your feedback before this Friday, March 14.
A couple of things: Debug mode needs to be broken out into directives for its real effects. I always want Zope to run as a daemon, but I also want automatic PT/DTML reloading, and immediate tracebacks. I think there should be a separate "no-detach" for those people who want that feature. The ZODB section doesn't work: Error: 'mount-point' is not a known key name Also, it needs to support arbitrary storage types. I don't know how ZConfig works internally, but I'm guessing each storage type would supply a ZConfig thingie that registers its configuration paramaters to ZConfig. I'm hoping to roll out some large production Zopes with partitioned, distributed storages. a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
Adrian van den Dries writes:
Debug mode needs to be broken out into directives for its real effects. I always want Zope to run as a daemon, but I also want automatic PT/DTML reloading, and immediate tracebacks. I think there should be a separate "no-detach" for those people who want that feature.
I'm happy with this (more so than the single option). I think it's fair for us to get this implemented before we're done; not sure if it has to happen before the merge (I'm mostly tied up this week).
The ZODB section doesn't work:
Error: 'mount-point' is not a known key name
I think we haven't spend enough time figuring out the right way to deal with DBTab-style mounts yet; leave out that key for now. To see the current spellings of the storage- and database-related configuration values, take a look at the ZConfig schema component in the ZODB package: lib/python/ZODB/component.xml
Also, it needs to support arbitrary storage types. I don't know how ZConfig works internally, but I'm guessing each storage type would supply a ZConfig thingie that registers its configuration paramaters to ZConfig. I'm hoping to roll out some large production Zopes with partitioned, distributed storages.
I'm not sure what you mean; it sounds like you're looking for either DBTab-style mounts or something different. Please describe the configuration so we can be sure that there's some way to support it. Thanks for your comments! -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Adrian van den Dries writes:
Debug mode needs to be broken out into directives for its real effects. I always want Zope to run as a daemon, but I also want automatic PT/DTML reloading, and immediate tracebacks. I think there should be a separate "no-detach" for those people who want that feature.
I'm happy with this (more so than the single option). I think it's fair for us to get this implemented before we're done; not sure if it has to happen before the merge (I'm mostly tied up this week).
The no-detach choice is already separate -- this is now an option to the separate zopectl program. --Guido van Rossum (home page: http://www.python.org/~guido/)
Fred L. Drake, Jr. wrote:
I'm not sure what you mean; it sounds like you're looking for either DBTab-style mounts or something different.
I certainly am. Since moving to DBTab, life suddenly seems so much easier! cheers, Chris
On March 10, Fred L. Drake, Jr. wrote:
I'm not sure what you mean; it sounds like you're looking for either DBTab-style mounts or something different. Please describe the configuration so we can be sure that there's some way to support it.
Yes, DBTab-style mounts are what I'm looking for. Shane says,
Hopefully, Zope 2.7 will integrate DBTab's functionality.
I took that at face value and assumed the rest of the crowd knew about it. DBTab's only limitation is that it has hard-coded storage types (most notably lacking is DirectoryStorage). The way I see this resolved is that DBTab knows nothing about storage types, but instead provides a mechanism for each storage to declare its configuration to ZConfig. I'm guessing the way to do that is to provide a ZConfig schema for each storage that declares what it needs configured, and a mount-point just needs a valid storage directive. Is this possible? I would also like to see the mounting mechanism work outside of Zope, so that you can partition a standalone ZODB application. That is outside the immediate scope of this thread, but something perhaps to keep in mind. a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
On Tue, Mar 11, 2003 at 12:11:25PM +1100, Adrian van den Dries wrote:
Debug mode needs to be broken out into directives for its real effects.
+9999999999999999999999999999L -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ULTRA PENGUIN! (random hero from isometric.spaceninja.com)
Hopefully I'll get to play with this later on in the week.. But here are the things I know I need as part of my business: -The ability to specify which python to use to build, install and run zope with. Our production machines have various version 1.5.2, 2.1.X, 2.2.X, etc installed. I must be able to specify the location. -The ability for each instance to have separate Product directories. Some users want plone, some don't. Some develop their own software. -The ability to start/stop zope without access to /proc (or the equivalent on other unices) on Linux. I don't know if the changes made affect any of the above ... but it would suck major #$W%% if it did. Oh, and part of my business if hosting zope ... if you are wondering where the above (off the top of my head list) comes from. Other than that it looks like the changes will be good for me. Oh and some way to have multiple zope versions installed at the same time would be great as well. :-) On Mon, 2003-03-10 at 15:41, Chris McDonough wrote:
Hi folks,
An effort to improve Zope 2 installation, startup, and configuration for Zope 2.7 has been ongoing for some time now (see http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration). The effort has reached a point where we believe it is reasonable to merge its fruits to the Zope trunk. Before doing so, however, we want to gather input from people who care deeply about Zope configuration and installation; particularly those who have significant investments in the existing behaviors of Zope 2 configuration and installation. A bunch of stuff is changed (most notably Zope no longer uses environment variables as configuration, and instead defers to command-line arguments and config file values).
What follows is a summary of changes, a walk-through of a Zope 2 installation under this regime, and a list of the configuration-file changeable parameters exposed by the current Zope configuration schema.
Please provide your feedback before this Friday, March 14. If possible, check out and try the new software. If there are showstopper issues for a lot of people, we will consider not performing the merge directly after that date. Otherwise, the merge will be performed at any time after the 14th.
Thanks!
- C
----- Major changes in Zope 2.7 =========================
Zope 2.7 will contain a number of changes related to the build process and configuration. The scripts used to start Zope will also be substantially changed. The implementation of these changes is not yet complete, but a substantial portion has been done and is expected to be merged into the Zope 2 trunk in the near future.
The exact schedule for merging these changes has not been determined; additional notice will be provided. These changes are substantially based on efforts by Chris McDonough on the "chrism-install-branch".
Major changes -------------
The following are the most important and user-visible changes compared to Zope 2.6 and the current CVS HEAD:
- Configuration is normally done by editing a config file instead of passing command line options. The configuration file is handled by the ZConfig package.
- Environment variables are no longer used for configuration.
- Building and installing the software have become more clearly distinct; the installation can be separate from the build.
- Zope 2.7 uses the "instance home" model in the normal case: a script in the installed software is used to create new "instances" of Zope. Each instance is defined by a directory tree containing configuration, scripts, and data. (For convenience, the instance and the installation can be located in the same directory, and the build area may be used in lieu of an installation if desired.)
- The z2.py, start, and stop scripts have been replaced by the runzope and zopectl scripts.
- The runzope/zopectl scripts do not accept the same command-line arguments as z2.py used to accept.
- The wo_pcgi.py script used to build Zope without PCGI support has been replaced by the common Unix build sequence of configure, make.
- The pcgi/ directory and the w_pcgi.py script have been removed from the top of the source tree. The pcgi/ directory may be made available as a separate distribution. (The application server still has support to allow connections from a PCGI-capable Web server.)
- The ZServer package has been moved from the top of the source tree into the lib/python/ directory.
Getting the code today ----------------------
The implementation lives in the "new-install-branch", which is a "partial" branch rather than a complete branch: only the files and directories which need to be changed have been placed on the branch; all other files are used from the CVS HEAD. The current state of this code can be checked out from CVS using the command:
cvs -d :pserver:anonymous@cvs.zope.org:/cvs-repository co \ -r new-install-branch -f Zope
The installation instructions in doc/INSTALL.txt has been updated on the branch; that file provides detailed information on creating an installation and instance. (A copy has been attached for convenience.)
A sample installation/startup runthrough ---------------------------------------
The below is the output from a sample install session. During this session, we install the Zope software to /tmp/zopehome and install an instance home to /tmp/insthome.
[chrism@james software]$ cd NewInstallBranch/ [chrism@james NewInstallBranch]$ ./configure --prefix=/tmp/zopehome
Configuring Zope installation
Testing for an acceptable Python interpreter...
Python version 2.1.3 found at /home/chrism/bin/python Python version 2.1.3 found at /home/chrism/bin/python2.1 Python version 2.2.2 found at /home/chrism/bin/python2.2
The optimimum Python version (2.2.2) was found at /home/chrism/bin/python2.2.
- Zope top-level binary directory will be /tmp/zopehome. - Makefile written.
Next, run make.
[chrism@james NewInstallBranch]$ make "/home/chrism/bin/python2.2" inst/setup.py -q build_ext -i <... compilation output elided ...>
Zope built. Next, do 'make install' (or 'make instance' to run a Zope instance directly from the build directory).
[chrism@james NewInstallBranch]$ make install <... installation output elided ...>
Zope binaries installed successfully. Now run '/tmp/zopehome/bin/mkzopeinstance'
[chrism@james NewInstallBranch]$ /tmp/zopehome/bin/mkzopeinstance mkzopeinstance requires exactly one argument
mkzopeinstance: Create a Zope instance home.
usage: mkzopeinstance [options] directory
Options:
-h/--help -- print this help text -u/--user NAME:PASSWORD -- set the user name and password of the initial user
[chrism@james NewInstallBranch]$ /tmp/zopehome/bin/mkzopeinstance \ --user=admin:123 /tmp/inst [chrism@james NewInstallBranch]$ cd /tmp/inst/ [chrism@james inst]$ ls bin etc Extensions import inituser log Products README.txt var [chrism@james inst]$ bin/zopectl start . daemon process started, pid=2947 [chrism@james inst]$ bin/zopectl stop . daemon process stopped
Changing the configuration via the config file ----------------------------------------------
The Zope configuration file uses the ZConfig API and file format. See the ZConfig documentation PDF at http://cvs.zope.org/Packages/ZConfig/doc/zconfig.pdf for more information.
The default Zope configuration file will live in the instance_home's /etc directory and will be named 'zope.conf'. The Zope configuration file allows you to change the following configuration variables:
instance home client home debug mode effective user production installation (on/off) locale number of zserver threads the python "check interval" (thread switch timing) zserver read only mode pid file name lock file name structured text header level publisher profile file (debugging) cgi environment dns server (hostname resolving in logfiles) ip address (for zserver bindings) http realm automatic quotation of dtml request data security manager stack size security policy implementation (C, Python) skip authentication checking skip ownership checking max number of session objects session "add notify" script path session "delete notify" script path session timeout minutes access rule suppress site root suppression database quota size read only database zeo client name logging (access, event, debug, filenames, to syslog, etc). network servers (http, dav, ftp, monitor, etc) databases (storages, database classes, etc.)
_______________________________________________ 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 ) -- Edward Muller
Interlix - President Web Hosting - PC Service & Support Custom Programming - Network Service & Support Phone: 417-862-0573 Cell: 417-844-2435 Fax: 417-862-0572 http://www.interlix.com
On Mon, 2003-03-10 at 22:13, Edward Muller wrote:
Hopefully I'll get to play with this later on in the week..
But here are the things I know I need as part of my business:
-The ability to specify which python to use to build, install and run zope with. Our production machines have various version 1.5.2, 2.1.X, 2.2.X, etc installed. I must be able to specify the location.
Yup. ./configure --with-python=/path/to/your/python
-The ability for each instance to have separate Product directories. Some users want plone, some don't. Some develop their own software.
This is inherent in INSTANCE_HOME behavior. The result of "mkzopeinstance" will contain a Products directory which may contain Zope software. Many instances can be configured to run from a single software home (a software home is the result of "make install")
-The ability to start/stop zope without access to /proc (or the equivalent on other unices) on Linux.
Yes.
I don't know if the changes made affect any of the above ... but it would suck major #$W%% if it did. Oh, and part of my business if hosting zope ... if you are wondering where the above (off the top of my head list) comes from. Other than that it looks like the changes will be good for me.
Oh and some way to have multiple zope versions installed at the same time would be great as well. :-)
Sure. In a Zope 2.7.0 source directory: ./configure --prefix=/opt/zope-2.7.0 make make install In a Zope 2.7.1 source directory: ./configure --prefix=/opt/zope-2.7.1 make make install ... then 'mkzopeinstance' from either. - C
Okay here is another one :-) given... ./configure --prefix=/opt/zope-2.7.0 make make install Once zope is installed in /opt/zope-2.7.0 can it be moved without damaging the install .... say to /home/virtual/some.host.name/opt/zope-2.7.0 ? In our hosting setup some things get run in a chroot, some things can't... Currently zope get's installed in a chroot environment for anyone who wants a zope install. It must be a complete install since when the user restarts it he will be in his chroot environment. So I'd ideally like to install zope in a way where all of the core of zope is in one place ... say ... /opt/zope/<version #> (/opt/zope/2.7.0, /opt/zope/2.7.1, etc...) This I can hardlink/symlink into each chroot and make permissions 755 root/root.
From there I would like to be able to install an 'instance', which is ... in my case meaning the data.fs, /Products directory, log files, etc, etc. The stuff that make this users instance theirs. When the install is happening, the script executing it would most likely be outside of the chroot ... but I guess it could be configured to chroot as well..
I already have start/stop scripts to go through the users that have a zope install and chroot into that users 'host' and then start zope as that 'hosts' administrative user. On Mon, 2003-03-10 at 21:47, Chris McDonough wrote:
On Mon, 2003-03-10 at 22:13, Edward Muller wrote:
Hopefully I'll get to play with this later on in the week..
But here are the things I know I need as part of my business:
-The ability to specify which python to use to build, install and run zope with. Our production machines have various version 1.5.2, 2.1.X, 2.2.X, etc installed. I must be able to specify the location.
Yup.
./configure --with-python=/path/to/your/python
-The ability for each instance to have separate Product directories. Some users want plone, some don't. Some develop their own software.
This is inherent in INSTANCE_HOME behavior. The result of "mkzopeinstance" will contain a Products directory which may contain Zope software. Many instances can be configured to run from a single software home (a software home is the result of "make install")
-The ability to start/stop zope without access to /proc (or the equivalent on other unices) on Linux.
Yes.
I don't know if the changes made affect any of the above ... but it would suck major #$W%% if it did. Oh, and part of my business if hosting zope ... if you are wondering where the above (off the top of my head list) comes from. Other than that it looks like the changes will be good for me.
Oh and some way to have multiple zope versions installed at the same time would be great as well. :-)
Sure.
In a Zope 2.7.0 source directory:
./configure --prefix=/opt/zope-2.7.0 make make install
In a Zope 2.7.1 source directory:
./configure --prefix=/opt/zope-2.7.1 make make install
... then 'mkzopeinstance' from either.
- C
_______________________________________________ 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 ) -- Edward Muller
Interlix - President Web Hosting - PC Service & Support Custom Programming - Network Service & Support Phone: 417-862-0573 Cell: 417-844-2435 Fax: 417-862-0572 http://www.interlix.com
On Tue, 2003-03-11 at 00:24, Edward Muller wrote:
Once zope is installed in /opt/zope-2.7.0 can it be moved without damaging the install .... say to /home/virtual/some.host.name/opt/zope-2.7.0 ?
Yes. Its location is only meaningful to the instance files that need to find it.
In our hosting setup some things get run in a chroot, some things can't...
Currently zope get's installed in a chroot environment for anyone who wants a zope install. It must be a complete install since when the user restarts it he will be in his chroot environment.
So I'd ideally like to install zope in a way where all of the core of zope is in one place ... say ... /opt/zope/<version #> (/opt/zope/2.7.0, /opt/zope/2.7.1, etc...)
This I can hardlink/symlink into each chroot and make permissions 755 root/root.
I think this will work. The only thing that might be a little weird is tracebacks generated by pyc files, as they may report the filenames of the Python modules where they were originally installed, instead of where they live now. There is some contention about whether this happens under Python 2.2, but I know it's true for Python 2.1 and prior.
From there I would like to be able to install an 'instance', which is ... in my case meaning the data.fs, /Products directory, log files, etc, etc. The stuff that make this users instance theirs. When the install is happening, the script executing it would most likely be outside of the chroot ... but I guess it could be configured to chroot as well..
You would need to chroot the run of makeinstance currently as it encodes paths to software within the instance files that start Zope. So if you ran it outside the chroot it would work, but when the user logged in to the chroot, the paths to the software would be wrong. I think this might be made configurable with a switch to mkzopeinstance (--sw_location=/some/path), though. I will add this to the tentative TODO, thanks.
I already have start/stop scripts to go through the users that have a zope install and chroot into that users 'host' and then start zope as that 'hosts' administrative user.
These scripts will unfortunately need to change for Zope 2.7 unless we create some sort of backwards compatibilty layer for startup. - C
On Tue, 2003-03-11 at 08:48, Chris McDonough wrote:
On Tue, 2003-03-11 at 00:24, Edward Muller wrote:
Once zope is installed in /opt/zope-2.7.0 can it be moved without damaging the install .... say to /home/virtual/some.host.name/opt/zope-2.7.0 ?
Yes. Its location is only meaningful to the instance files that need to find it.
In our hosting setup some things get run in a chroot, some things can't...
Currently zope get's installed in a chroot environment for anyone who wants a zope install. It must be a complete install since when the user restarts it he will be in his chroot environment.
So I'd ideally like to install zope in a way where all of the core of zope is in one place ... say ... /opt/zope/<version #> (/opt/zope/2.7.0, /opt/zope/2.7.1, etc...)
This I can hardlink/symlink into each chroot and make permissions 755 root/root.
I think this will work. The only thing that might be a little weird is tracebacks generated by pyc files, as they may report the filenames of the Python modules where they were originally installed, instead of where they live now. There is some contention about whether this happens under Python 2.2, but I know it's true for Python 2.1 and prior.
Well I can install zope in /opt/zope/2.7.1 (in the real root) and then when I symlink/hardlink it into a virtual host I can link it into that hosts /opt/zope/2.7.1 ... So that's not a biggie....
From there I would like to be able to install an 'instance', which is ... in my case meaning the data.fs, /Products directory, log files, etc, etc. The stuff that make this users instance theirs. When the install is happening, the script executing it would most likely be outside of the chroot ... but I guess it could be configured to chroot as well..
You would need to chroot the run of makeinstance currently as it encodes paths to software within the instance files that start Zope. So if you ran it outside the chroot it would work, but when the user logged in to the chroot, the paths to the software would be wrong.
That's not a problem ... at least IIRC. I can chroot when creating the account in a shell script and execute custom setup scripts.
I think this might be made configurable with a switch to mkzopeinstance (--sw_location=/some/path), though. I will add this to the tentative TODO, thanks.
all thought that would be nice.
I already have start/stop scripts to go through the users that have a zope install and chroot into that users 'host' and then start zope as that 'hosts' administrative user.
These scripts will unfortunately need to change for Zope 2.7 unless we create some sort of backwards compatibilty layer for startup.
Yeah. Oh well. They aren't that complex. :-) I wouldn't worry about the backward compatibility layer myself. I don't know if there is a great value add to it, aside from keeping users from going 'WTF happened?' :-) -- Edward Muller Interlix - President Web Hosting - PC Service & Support Custom Programming - Network Service & Support Phone: 417-862-0573 Cell: 417-844-2435 Fax: 417-862-0572 http://www.interlix.com
We currently rely on two scripts for running our Zopes: 1. A modified version of zctl.py. I originally got it from a moribund wiki on the Zope site. The main changes we've made have been to better separate parameters for Zope clients from parameters for the ZEO server and to run an additional server of our own along side the ZEO server (a simple distributed RAM Cache invalidation server). 2. A very simple sysv-init script that implements everything by calling the correct zctl.py. It looks like the new install and startup world will be a huge improvement over the current setup on the whole. I like moving the log files to their own directory. The things that seemed to be missing from your writeup were: Almost no mention of ZEO (only one mention of a "zeo client name" parameter). How does ZEO fit into this? I don't see an equivalent to "./zctl.py debug" anywhere. This starts up an interactive Python as a ZEO client with ZServer and Zope imported and app = Zope.app(). I use it constantly. Please?
The things that seemed to be missing from your writeup were:
Almost no mention of ZEO (only one mention of a "zeo client name" parameter). How does ZEO fit into this?
ZEO client configuration is included in the new configuration schema. ZEO server configuration has its own schema and tools, also based on ZConfig and the new zdaemon; you can check these out in the ZODB 3.2 alpha release. --Guido van Rossum (home page: http://www.python.org/~guido/)
--On Tuesday, March 11, 2003 10:17:08 AM -0500 Guido van Rossum <guido@python.org> wrote:
ZEO client configuration is included in the new configuration schema.
ZEO server configuration has its own schema and tools, also based on ZConfig and the new zdaemon; you can check these out in the ZODB 3.2 alpha release.
Does this mean that Zope 2.7 will require ZODB 3.2 for ZEO users? As an aside, am I the only one who's confused by this new bundling of ZEO as part of the stand alone ZODB product? Dan Pierson
ZEO client configuration is included in the new configuration schema.
ZEO server configuration has its own schema and tools, also based on ZConfig and the new zdaemon; you can check these out in the ZODB 3.2 alpha release.
Does this mean that Zope 2.7 will require ZODB 3.2 for ZEO users?
Zope 2.7 will *come with* ZODB 3.2 (or later, depending on the timing of the Zope 2.7 release), so I suppose so.
As an aside, am I the only one who's confused by this new bundling of ZEO as part of the stand alone ZODB product?
I don't know. What's confusing for you? The new approach is that: Zope includes ZODB includes ZODB What's confusing about that? --Guido van Rossum (home page: http://www.python.org/~guido/)
--On Tuesday, March 11, 2003 02:39:55 PM -0500 Guido van Rossum <guido@python.org> wrote:
Does this mean that Zope 2.7 will require ZODB 3.2 for ZEO users?
Zope 2.7 will *come with* ZODB 3.2 (or later, depending on the timing of the Zope 2.7 release), so I suppose so. ...
As an aside, am I the only one who's confused by this new bundling of ZEO as part of the stand alone ZODB product?
I don't know. What's confusing for you? The new approach is that:
Zope includes ZODB includes ZODB
What's confusing about that?
Zope doesn't (currently) include ZEO so to get an up to date ZEO we now have to obtain the correct version of the stand-alone ZODB and extract the contained ZEO. The version numbers of the ZEO and stand-alone ZODB are unrelated so figuring out which ZODB we need to get ZEO is a bit of a pain. Also, ZEO is packaged differently in the stand alone ZODB than it used to be in on it's own. Dan Pierson
Zope doesn't (currently) include ZEO so to get an up to date ZEO we now have to obtain the correct version of the stand-alone ZODB and extract the contained ZEO. The version numbers of the ZEO and stand-alone ZODB are unrelated so figuring out which ZODB we need to get ZEO is a bit of a pain. Also, ZEO is packaged differently in the stand alone ZODB than it used to be in on it's own.
That's why we're including the correct versions of ZODB and ZEO in Zope itself. That's already the case in Zope 2.6. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, 2003-03-11 at 15:22, Guido van Rossum wrote:
That's why we're including the correct versions of ZODB and ZEO in Zope itself. That's already the case in Zope 2.6.
Zope 2.6 doesn't yet include ZEO, at least I don't think it does. ;-) - C
On Tue, 2003-03-11 at 15:22, Guido van Rossum wrote:
That's why we're including the correct versions of ZODB and ZEO in Zope itself. That's already the case in Zope 2.6.
Zope 2.6 doesn't yet include ZEO, at least I don't think it does. ;-)
Oops, I stand corrected. But Zope 2.7 does include ZEO! --Guido van Rossum (home page: http://www.python.org/~guido/)
--On Tuesday, March 11, 2003 03:43:33 PM -0500 Guido van Rossum <guido@python.org> wrote:
On Tue, 2003-03-11 at 15:22, Guido van Rossum wrote:
That's why we're including the correct versions of ZODB and ZEO in Zope itself. That's already the case in Zope 2.6.
Zope 2.6 doesn't yet include ZEO, at least I don't think it does. ;-)
Oops, I stand corrected. But Zope 2.7 does include ZEO!
Very good! But in that case, shouldn't the new Zope 2.7 install and startup stuff support it?
Oops, I stand corrected. But Zope 2.7 does include ZEO!
Very good! But in that case, shouldn't the new Zope 2.7 install and startup stuff support it?
Well, in a typical installation, you won't be running ZEO on the same machine as Zope, right? ZEO has its own install and config stuff, which is very similar to that for Zope, but ZEO is not installed as part of the main Zope install. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Well, in a typical installation, you won't be running ZEO on the same machine as Zope, right? ZEO has its own install and config stuff, which is very similar to that for Zope, but ZEO is not installed as part of the main Zope install.
I routinely run ZEO on all of my sites, on the same machine. I don't gain any "scalability" benefits this way, but it is fantastic for debugging and tweaking a live site. My creaky old zctl.py auto-starts ZEO when necessary, using the same configuration data as it uses for the associated Zope instance, so they both know to use 'var/zeo.soc' to connect. Cheers, Evan @ 4-am
I routinely run ZEO on all of my sites, on the same machine. I don't gain any "scalability" benefits this way, but it is fantastic for debugging and tweaking a live site.
My creaky old zctl.py auto-starts ZEO when necessary, using the same configuration data as it uses for the associated Zope instance, so they both know to use 'var/zeo.soc' to connect.
zdrun takes care of auto-restart. Sharing config data may be a little trickier; Fred and/or Chris should know more about that. --Guido van Rossum (home page: http://www.python.org/~guido/)
--On Tuesday, March 11, 2003 04:05:32 PM -0600 Evan Simpson <evan@4-am.com> wrote:
I routinely run ZEO on all of my sites, on the same machine. I don't gain any "scalability" benefits this way, but it is fantastic for debugging and tweaking a live site.
My creaky old zctl.py auto-starts ZEO when necessary, using the same configuration data as it uses for the associated Zope instance, so they both know to use 'var/zeo.soc' to connect.
Yep, that's just what I do. Using a variant of your creaky old zctl.py in fact.
On Tue, Mar 11, 2003 at 04:25:09PM -0500, Guido van Rossum wrote:
Oops, I stand corrected. But Zope 2.7 does include ZEO!
Very good! But in that case, shouldn't the new Zope 2.7 install and startup stuff support it?
Well, in a typical installation, you won't be running ZEO on the same machine as Zope, right? ZEO has its own install and config stuff, which is very similar to that for Zope, but ZEO is not installed as part of the main Zope install.
i suppose it's not typical but we run zeo on all our systems including the dev boxes, because * we like to have the same environment everywhere for sanity's sake * interactive debugging is very cool and has saved my butt more than once. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's FAT BOY! (random hero from isometric.spaceninja.com)
On Tue, 2003-03-11 at 16:12, Dan L. Pierson wrote:
Very good! But in that case, shouldn't the new Zope 2.7 install and startup stuff support it?
It does. It's just that the default setup is still to use a non-ZEOd FileStorage for your main database. But you can change options in the config file to make it use a ZEO ClientStorage. This is in lieu of of requiring you to edit custom_zodb.py as you needed to do in 2.6 and prior. It's clear that the Zope source distro should support the use of ClientStorage "out of the box". It's not however so clear that the Zope source distro should make it to set up a ZEO server (although it does happen to include the necessary files to run a ZEO server too, it doesn't include a 'zeoctl' or a zeo.conf, etc). That's not to say that it shouldn't be easy to set up a ZEO server, but that making it easy should probably the job of a package other than Zope proper. The right thing to do would be to package up a ZEO server installer separate from Zope 2.7 with a similar kind of buildout, support files, and configuration file. At least that's been my idea so far. - C
Very good! But in that case, shouldn't the new Zope 2.7 install and startup stuff support it?
It does. It's just that the default setup is still to use a non-ZEOd FileStorage for your main database. But you can change options in the config file to make it use a ZEO ClientStorage. This is in lieu of of requiring you to edit custom_zodb.py as you needed to do in 2.6 and prior.
It's clear that the Zope source distro should support the use of ClientStorage "out of the box". It's not however so clear that the Zope source distro should make it to set up a ZEO server (although it does happen to include the necessary files to run a ZEO server too, it doesn't include a 'zeoctl' or a zeo.conf, etc).
Chris, have you looked at ZEO/mkzeoinst.py? It uses a somewhat simpler approach than the new Zope setup, but it creates a zeoctl script and a zeo.conf configuration file.
That's not to say that it shouldn't be easy to set up a ZEO server, but that making it easy should probably the job of a package other than Zope proper. The right thing to do would be to package up a ZEO server installer separate from Zope 2.7 with a similar kind of buildout, support files, and configuration file. At least that's been my idea so far.
Not needed; it's all there (though far simpler in approach than the Zope installer). --Guido van Rossum (home page: http://www.python.org/~guido/)
Cool! I didn't know. Do you think we should tell people that if they want to run a ZEO server to just run mkzeoinst from the software home resulting from Zope's "make install" and to edit zope.conf to use a ClientStorage?
Chris, have you looked at ZEO/mkzeoinst.py? It uses a somewhat simpler approach than the new Zope setup, but it creates a zeoctl script and a zeo.conf configuration file.
Chris, have you looked at ZEO/mkzeoinst.py? It uses a somewhat simpler approach than the new Zope setup, but it creates a zeoctl script and a zeo.conf configuration file.
Cool! I didn't know.
Do you think we should tell people that if they want to run a ZEO server to just run mkzeoinst from the software home resulting from Zope's "make install" and to edit zope.conf to use a ClientStorage?
That should work, yes, as long as mkzeoinst.py, zdctl.py, zdrun.py and runzeo.py are all on $PATH at that point. --Guido van Rossum (home page: http://www.python.org/~guido/)
Chris McDonough wrote at 2003-3-11 15:32 -0500:
On Tue, 2003-03-11 at 15:22, Guido van Rossum wrote:
That's why we're including the correct versions of ZODB and ZEO in Zope itself. That's already the case in Zope 2.6.
Zope 2.6 doesn't yet include ZEO, at least I don't think it does. ;-)
When you make a CVS checkout of the 2.6 branch, it already contains ZEO. Dieter
On Tue, Mar 11, 2003 at 10:01:53AM -0500, Dan L. Pierson wrote:
I don't see an equivalent to "./zctl.py debug" anywhere. This starts up an interactive Python as a ZEO client with ZServer and Zope imported and app = Zope.app(). I use it constantly. Please?
+1. I also use zctl.py debug nearly every day. of course it's just a convenience, but it's an important convenience because nearly every document i can find on debugging Zope says roughly "...and of course you can use ZEO, but that's beyond the scope of this article..." -- Paul Winkler http://www.slinkp.com
Chris McDonough wrote at 2003-3-10 16:41 -0500:
... - Configuration is normally done by editing a config file instead of passing command line options. The configuration file is handled by the ZConfig package.
- Environment variables are no longer used for configuration.
I am *very* sad about this. Configuration via environment variables is easy and much more flexible than configuration files: We use a single configuration for a farm of Zopes. Of course, each Zope needs its own ZEO client cache, its own log file, its own pid files, .... All this is achieved by incorporating the result of "hostname" into the respective environment variables. I do not know how to do something like this in a configuration file (unless it provides for some form of shell functionality). Howfully, the configuration file supports (at least) definition of "key constants" (like hostname) and its interpolation in other modular (and reusable) components.
- Building and installing the software have become more clearly distinct; the installation can be separate from the build.
Seems you make the elementary installation more difficult. Advanced installations may get easier, though... Dieter
On Tue, 2003-03-11 at 17:11, Dieter Maurer wrote:
All this is achieved by incorporating the result of "hostname" into the respective environment variables.
I do not know how to do something like this in a configuration file (unless it provides for some form of shell functionality).
ZConfig does allow you to declare and use simple bash-style variables within a single file, but currently provides no access to the environment. I suspect we could add something to obtain an envvar value within ZConfig. E.g.: %define HOSTNAME ${HOSTNAME} .. then refer to $HOSTNAME in the rest of the config file... (squiggly brackets would mean obtain from environment). Do you think this would suffice? Or maybe we just make HOSTNAME and/or IP_ADRRESS within the a "key constant" as you describe.
- Building and installing the software have become more clearly distinct; the installation can be separate from the build.
Seems you make the elementary installation more difficult.
I'm surprised at this assertion. The most elementary way of install under 2.7 is this: $ cd Zope-src $ ./configure {finds suitable Python and reports lack of large file support} $ make $ make install $ /opt/zope/mkzopeinstance /tmp/inst {user edits /tmp/inst/etc/zope.conf, which has inline docs} $ /tmp/inst/zopectl start While under 2.6 it's this: {need to know to configure Python with largefile support} $ cd Zope-src $ /path/to/python/version/you/want wo_pcgi.py {user finds and reads doc/ENVIRONMENT.txt for envvars} {user finds and reads z2.py for command-line switches} {user edits the 'start' script with the right switches and envvars} $ ./start (Forgot to mention the auto-large-file-detection support in the configure script in the original request for comments, sorry). I think most folks new to Zope would pick up on the first path sooner than the latter as it more closely follows the setup directions of programs they're already used to (Apache, for instance). It also provides the least amount of suprise in the long term. For example, how many times have we had to talk panicked people through a recovery effort after they've run in to the 2GB limit on some UNIX variant because they're running a Python without largefile support? Anyway, I think the requirement to be able to access the environment under ZConfig is a good suggestion. If you could expand on why you think elementary installation is now harder, I would like to hear that. - C
Hi Chris, Chris McDonough wrote at 2003-3-11 18:39 -0500:
On Tue, 2003-03-11 at 17:11, Dieter Maurer wrote:
All this is achieved by incorporating the result of "hostname" into the respective environment variables.
I do not know how to do something like this in a configuration file (unless it provides for some form of shell functionality).
ZConfig does allow you to declare and use simple bash-style variables within a single file,
When the configuration is composed out of components (e.g. for packages), then some global declarations might be very useful. I.e. a features as the global parameters in XSLT. This would allow to have a single place to change all dependent components (locations are most likely candidates for this feature).
but currently provides no access to the environment. I suspect we could add something to obtain an envvar value within ZConfig.
E.g.:
%define HOSTNAME ${HOSTNAME}
.. then refer to $HOSTNAME in the rest of the config file...
(squiggly brackets would mean obtain from environment).
Do you think this would suffice?
For us, it would. But the syntax could be a bit more explicit, maybe ${env HOSTNAME} (a la "make", where the first word in "${...}" may be a function).
Or maybe we just make HOSTNAME and/or IP_ADRRESS within the a "key constant" as you describe.
I like access to the environment more.
- Building and installing the software have become more clearly distinct; the installation can be separate from the build.
Seems you make the elementary installation more difficult.
I'm surprised at this assertion. The most elementary way of install under 2.7 is this:
$ cd Zope-src $ ./configure {finds suitable Python and reports lack of large file support} $ make $ make install $ /opt/zope/mkzopeinstance /tmp/inst {user edits /tmp/inst/etc/zope.conf, which has inline docs} $ /tmp/inst/zopectl start
While under 2.6 it's this:
{need to know to configure Python with largefile support} $ cd Zope-src $ /path/to/python/version/you/want wo_pcgi.py {user finds and reads doc/ENVIRONMENT.txt for envvars} {user finds and reads z2.py for command-line switches} {user edits the 'start' script with the right switches and envvars} $ ./start
I never read "ENVIRONMENT.txt"; for elementary use, I need neither read "z2.py" nor do anything with "start". These things may come later, when newbies are already a bit acquainted with Zope. Dieter
On Thu, 2003-03-13 at 16:14, Dieter Maurer wrote:
ZConfig does allow you to declare and use simple bash-style variables within a single file,
When the configuration is composed out of components (e.g. for packages), then some global declarations might be very useful. I.e. a features as the global parameters in XSLT. This would allow to have a single place to change all dependent components (locations are most likely candidates for this feature).
OK, I'll add this to the list of desired features as well, thanks.
but currently provides no access to the environment. I suspect we could add something to obtain an envvar value within ZConfig.
E.g.:
%define HOSTNAME ${HOSTNAME}
.. then refer to $HOSTNAME in the rest of the config file...
(squiggly brackets would mean obtain from environment).
Do you think this would suffice?
For us, it would.
But the syntax could be a bit more explicit, maybe ${env HOSTNAME} (a la "make", where the first word in "${...}" may be a function).
We'll try out a couple different spellings I think. Currently we support both $NAME and ${NAME} (I fought hard against the former and lost), so we'll need to be creative.
I never read "ENVIRONMENT.txt"; for elementary use, I need neither read "z2.py" nor do anything with "start".
These things may come later, when newbies are already a bit acquainted with Zope.
OK. I think the config file is a bit more approachable for newbies, especially non-developer newbies who really don't care all that much about Zope and just want to get it set up for people who are developers. But to each his own. - C
Small problem. The 'make install' step creates files in the source tree. It probably shouldn't do this, because if you want to do this as root (sudo make install to install under /usr/local, say), these file are created as root. This is impolite more than anything else. The build and install targets just call setup.py, so is this a bug in the distutils? a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
Adrian van den Dries writes:
The 'make install' step creates files in the source tree. It probably shouldn't do this, because if you want to do this as root (sudo make install to install under /usr/local, say), these file are created as root. This is impolite more than anything else.
The build and install targets just call setup.py, so is this a bug in the distutils?
This still essentially does an "in place" build, which is what the previous Makefile did as well. Offhand, I'm not sure how difficult it would be to support both in-place and out-of-place builds; I may be able to look into it tomorrow. How important is it to support out-of-place builds? -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On March 19, Fred L. Drake, Jr. wrote:
How important is it to support out-of-place builds?
http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration
configure; make; make install source package installation process and some form of INSTANCE_HOME installation thereafter.
INSTANCE_HOME setup becomes the default kind of installation.
Is this still current? a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
Adrian van den Dries writes:
On March 19, Fred L. Drake, Jr. wrote:
How important is it to support out-of-place builds?
http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration
Ok, I'm too tired to read that now; I'll look at it tomorrow between meetings.
configure; make; make install source package installation process and some form of INSTANCE_HOME installation thereafter.
INSTANCE_HOME setup becomes the default kind of installation.
Is this still current?
Can't say about the wiki offhand, but the quoted statement still applies. doc/INSTALL.txt has been updated; see the section "Building Zope" for the relevant procedure. (The "Quick Start" section uses an abbreviated procedure that creates an instance home in the source directory.) Time for me to get some sleep. ;-) -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On March 19, Fred L. Drake, Jr. wrote:
(The "Quick Start" section uses an abbreviated procedure that creates an instance home in the source directory.)
It calls configure with --prefix=/where/to/install/zope which is then unused. a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
'make install' should not create files in the source tree as long as you've run 'make' beforehand. Which files does it create? On Wed, 2003-03-19 at 01:04, Adrian van den Dries wrote:
Small problem.
The 'make install' step creates files in the source tree. It probably shouldn't do this, because if you want to do this as root (sudo make install to install under /usr/local, say), these file are created as root. This is impolite more than anything else.
The build and install targets just call setup.py, so is this a bug in the distutils?
a.
-- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
On March 20, Chris McDonough wrote:
'make install' should not create files in the source tree as long as you've run 'make' beforehand. Which files does it create?
These directories and everything below them: ./build ./lib/python/build/lib ./lib/python/build/lib.linux-i686-2.2 ./lib/python/build/scripts-2.2 Perhaps the build target should do a 'setup.py build' rather than 'setup.py build_ext'? a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
participants (12)
-
Adrian van den Dries -
Chris McDonough -
Chris Withers -
Dan L. Pierson -
Dieter Maurer -
Edward Muller -
Evan Simpson -
Fred L. Drake, Jr. -
Guido van Rossum -
Jamie Heilman -
Paul Winkler -
Steve Alexander