[Zope-dev] Re: [Zope] Proposed installation changes for review
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/ (/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 - [EMAIL PROTECTED] > 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 ___ 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 )
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
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) ___ 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 )
[Zope-dev] Re: [Zope] Proposed installation changes for review
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-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 )
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
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. PythonLabs at Zope Corporation ___ 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 )
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
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 ___ 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 )
[Zope-dev] Re: [Zope] Proposed installation changes for review
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
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
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 ___ 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 )
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
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 ___ 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 )
Re: [Zope-dev] Proposed installation changes for review
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. +L -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ULTRA PENGUIN! (random hero from isometric.spaceninja.com) ___ 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 )
[Zope-dev] product import question
We have developed a zope product that works (as expected) as a standalone - call it prodA. We have another product that simply exposes a number of utility container objects that when created, provide certain functions at different levels. They also restrict meta_types at each level. Call this prodB. A fully developing prodB might look something like this: resourceStore resourceFolder datasourceFolder dbFolder I attempted to restrict the meta_types in the class that is represented by dbFolder to just prodA. In order to gain access to the prodA add form, I had to import the prodA module into the prodB module and make the assignment in the class that is represented by dbFolder. At this point the single factory method was exposed in the dbFolder as expected. Unfortuantely, the constructor for prodA (action of the prodA add form) could not be found. With numerous tweakings and source searching I settled on duplicating the constructor function for prodA in the class that is represented by dbFolder. Now it works. The question I have... is this the right way to do this?? I attempted to do a 'from prodA-module import prodA-constructor-function' and that didn't help. I tried a number of other incantations to no avail. The interesting thing (for me) was that if I did not restrict meta_types in dbFolder and just used the default factory-method list (of which prodA was one) I could create prodA without importing anything from the prodA module. I know I am being dense here but the obvious alludes me here. Any enlightenment would be much appreciated... TIA Eric ___ 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 )
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
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:
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
___
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 )
Re: [Zope-dev] Proposed installation changes for review
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. PythonLabs at Zope Corporation ___ 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 )
Re: [Zope-dev] Proposed installation changes for review
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 [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ 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 )
Re: [Zope-dev] Proposed installation changes for review
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. [EMAIL PROTECTED] inst]$ bin/zopectl program: /tmp/inst/bin/runzope daemon manager not running zdctl> ? Documented commands (type help ): fg foreground helpkill logreopen logtail quitreload restart shell showstart status stopwait Undocumented commands: == EOF zdctl> fg export EVENT_LOG_FILE EVENT_LOG_FILE= /tmp/inst/bin/runzope HTH, - 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 )
Re: [Zope-dev] Proposed installation changes for review
> - 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
___
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 )
Re: [Zope-dev] Proposed installation changes for review
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 ___ 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 )
[Zope-dev] 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:[EMAIL PROTECTED]:/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. [EMAIL PROTECTED] software]$ cd NewInstallBranch/ [EMAIL PROTECTED] 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. [EMAIL PROTECTED] NewInstal
[Zope-dev] "Fuzziness" in tracebacks ...
Hi! I am using Zope 2.6.1 with Python 2.2.2, knowing that this is not officially supported. There are no problems in general, but one thing really is annoying: I start getting tracebacks that only indicate the line in the code where the method that caused the traceback started. I don't get the actual line of the error traced down. This might be completely independent of using Python 2.2.2, so I'd like to know if anybody else has made similar experiences with 2.6.1. Another issue that might or might not be related is that I am getting plain white pages rendered by ZPT if there is an error calling a variable or so. Errors in the ZPT syntax and some runtime errors are raised properly, but others just cause a white page to be rendered, which is very hard to debug without using a debugger. Joachim -- iuveno AG Joachim Werner _ Wittelsbacherstr. 23b 90475 Nürnberg [EMAIL PROTECTED] www.iuveno.de Tel.: +49 (0) 911/ 9 88 39 84 ___ 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 )
Re: [Zope-dev] Stupid dtml-if comparision
David Cain wrote: I'm trying to compare two number, or at least I think they're numbers. You should be asking this on [EMAIL PROTECTED] If I do: Equal block I and J print out the same, but do not compare to be equal since "Equal block" string doesn't print. ...and this should be in a python script! print i print j if i==j: print "Equal block" return printed DTML sucks for this, as you can see, because it evaluates things in interesting and unexpected ways... cheers, Chris ___ 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 )
Re: [Zope-dev] Re: [Vote] PEP308 voting began
Paul Winkler wrote: +sys.maxint "ugly" python expressions in ZPT is to me a clear signal that you need to refactor and that's a GOOD THING. And refactoring is easy when you can just start by copy / pasting the python expressions into a Script. If they were some new-fangled "if: then: else:" syntax in TAL, you'd have to rewrite from scratch... and we're right back in the mess we got into with DTML: the poor developer is forced to learn many ways of doing the same thing. +OO (that's infinity in case it's not clear...) cheers, Chris ___ 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 )
Re: [Zope-dev] How to trigger Zope externally (mail)
Ross Boylan wrote: On Wed, Feb 26, 2003 at 05:37:17PM -0800, Andy McKay wrote: Or just write a simple HTTP post using Python. Have a look around for the MailIn Product, or CMFMailIn which does this very simply and works fine for low volume traffic (eg: fine listening to [EMAIL PROTECTED]). Thanks. I borrowed from CMFMailIn; I couldn't find the MailIn product. http://www.zope.org/Members/NIP/ZMailIn/ cheers, Chris ___ 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 )
