Re: [Zope-dev] Re: zcml entry points
Martin Aspeli wrote: Fred Drake wrote: On 10/17/07, Wichert Akkerman [EMAIL PROTECTED] wrote: A common issue we are seeing is that we have eggs depending on each other, but they still need to load the zcml from those dependencies somehow. As a temporary solution to play with the concept I added something simple to the plone.recipe.zope2instance buildout recipe. What's the problem you're seeing? I'm not sure what you're trying to solve. ZCML includes work just fine in the egg world. As long as you're referring to packaged ZCML using package=package.name in your include and includeOverrides directives, all is good. The main win, IMHO, is to avoid the requirement for people to install slugs for third party products. Slugs suck - they are confusing to explain and people forget them all the time. Buildout makes it a bit easier, but it's still not a terribly good solution. For example, say you want to install oi.plum. You need to add the line 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your buildout.cfg. Forget the latter, and the package doesn't work properly (or at all). I see a different win. At the moment we are declaring dependencies in two places: in the egg information and in the zcml files. For every package I need I need to make sure its zcml is loaded, which means I need to have a meta.zcml, configure.zcml and overrides.zcml which load the meta, configure and overrides from all packages I depend on. I also need to inspect every package I depend on to check if they have a meta, configure or overrides.zcml, which in my humble opinion should be just an implementation detail that I, as someone who is just using the zope stack/framework, should not need to know about. Multiply that with the number of dependencies you see in zope.* and you see this becomes very unwieldy. So I turned things around: if I state in my egg information that I require another package that means I need to have that package available and functional. Which suggests that its zcml has to be loaded before mine. And that is exactly what I am doing: adding an entry point that allows a package to say in order to function I need to have these zcml files loaded. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
[Zope-dev] Re: Schedule for Zope 2.11
I've checked in my datetime.datetime conversions patch Is there any reason that the pytz import is not required? I would like to add support for conversion to timezone aware datetimes, and would like to rely on pytz being available. Laurence Amos Latteier wrote: On 10/17/07, Laurence Rowe [EMAIL PROTECTED] wrote: Amos, Are you planning to merge your pytz work to trunk? Done. -Amos ___ 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 ) ___ 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 )
[Zope-dev] buildbot failure in Zope trunk 2.4 Windows 2000 zc-bbwin6
The Buildbot has detected a failed build of Zope trunk 2.4 Windows 2000 zc-bbwin6. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2581 Blamelist: brandon_rhodes,ldr,ulif BUILD FAILED: failed test sincerely, -The Buildbot ___ 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 )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Wed Oct 17 12:00:00 2007 UTC to Thu Oct 18 12:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Oct 17 20:52:38 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008506.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Oct 17 20:54:08 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008507.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Oct 17 20:55:38 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008508.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Oct 17 20:57:08 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008509.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Oct 17 20:58:38 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008510.html ___ 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 )
[Zope-dev] Re: zcml entry points
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: Martin Aspeli wrote: Fred Drake wrote: On 10/17/07, Wichert Akkerman [EMAIL PROTECTED] wrote: A common issue we are seeing is that we have eggs depending on each other, but they still need to load the zcml from those dependencies somehow. As a temporary solution to play with the concept I added something simple to the plone.recipe.zope2instance buildout recipe. What's the problem you're seeing? I'm not sure what you're trying to solve. ZCML includes work just fine in the egg world. As long as you're referring to packaged ZCML using package=package.name in your include and includeOverrides directives, all is good. The main win, IMHO, is to avoid the requirement for people to install slugs for third party products. Slugs suck - they are confusing to explain and people forget them all the time. Buildout makes it a bit easier, but it's still not a terribly good solution. For example, say you want to install oi.plum. You need to add the line 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your buildout.cfg. Forget the latter, and the package doesn't work properly (or at all). I see a different win. At the moment we are declaring dependencies in two places: in the egg information and in the zcml files. For every package I need I need to make sure its zcml is loaded, which means I need to have a meta.zcml, configure.zcml and overrides.zcml which load the meta, configure and overrides from all packages I depend on. I also need to inspect every package I depend on to check if they have a meta, configure or overrides.zcml, which in my humble opinion should be just an implementation detail that I, as someone who is just using the zope stack/framework, should not need to know about. Multiply that with the number of dependencies you see in zope.* and you see this becomes very unwieldy. So I turned things around: if I state in my egg information that I require another package that means I need to have that package available and functional. Which suggests that its zcml has to be loaded before mine. And that is exactly what I am doing: adding an entry point that allows a package to say in order to function I need to have these zcml files loaded. I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. I think that the library vs. pluggable application distinction is valid here: maybe you want to define an entry point in the egg which a given pluggable app would use at startup time to configure all the plugins which exposed that entry point. Five fakes such an entry point now by implicitly loading meta.zcml, then configure.zcml, then overrides.zcml for all packages it recognizes as products: are you proposing to replace Five's DWIM with a new, explicit version? Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFHF07w+gerLs4ltQ4RApigAJQKD7QktS+kRjxD3XiJ76p/QEjXAKCuhpNk oKng4r5TQOJiuL9WFZst0A== =91pF -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] Re: zcml entry points
On Oct 17, 2007, at 8:04 PM, Ross Patterson wrote: ... I'm new to eggs, but maybe both sides could be satisfied with an approach like extra_requires? Extras are evil. See other posts of mine for explanations of why. You could list oi.plum [zope.zcml] when you require oi.plum *and* its ZCML and then it's ZCML would get loaded. Is this easily possible with eggs and/or buildout? easy_install has nothing to do with loading ZCML. A recipe could do something, but extra-requires don't help in any useful way. Jim -- Jim Fulton Zope Corporation ___ 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 )
Re: [Zope-dev] zcml entry points
On Oct 17, 2007, at 4:44 PM, Wichert Akkerman wrote:
A common issue we are seeing is that we have eggs depending on each
other, but they still need to load the zcml from those dependencies
somehow. As a temporary solution to play with the concept I added
something simple to the plone.recipe.zope2instance buildout recipe.
It allows you to define entrypoints like this:
entry_points={
zope.zcml : [
meta = plone.session,
configure = plone.session,
],
},
this tells the system to load meta.zcml and configure.zcml from
plone.session.
Sure, where presumably you could list multiple files.
Or maybe:
entry_points =
[zcml]
meta = include package=plone.session /
configure = include package=plone.session /
...
entry_points=entry_points
(This example uses the ConfigParser syntax for specifying entry
points, which I prefer.)
This suggestion gives you the flexibility to specify ZCML to be
included by package name, by file name, or both.
It lets you specify other ZCML as well.
entry_points={
zope.zcml : [
meta = plone.session,
configure = plone.session,
],
},
I am not quite sure what the best way to hook this into Zope itself
is.
For Zope 2 we can do it in Five, since that is where all the zcml
loading
logic currently is. Or we could move that into Zope2 itself somewhere.
I'm not familiar enough with Zope3 to know what the best place
would be there.
I recommend creating new configuration directives that do this.
include meta_entry_points /
include entry_points /
These directives might also accept an projects attribute to name
specific eggs, by project name, to load from.
This could be used in Zope 2 and in Zope 3 apps that want it. (Mine
wouldn't. :)
Doing it this way keeps it simple to use while providing some added
flexibility to do explicit configuration before or after this
automatic configuration.
One problem is ordering: the zope.component zcml needs to be loaded
first.
As Tres noted, a package that needs zope.component to be included
should include it. In general, I recommend that a package include
all of the ZCML it expects to be included.
I understand that some folks would fine something like this to be
very useful. I can especially see the benefit for pluggable apps,
like Plone and Zope 2.. I support this idea. I would almost
certainly not use it myself and can't justify my time to implement
this. I think the implementation is pretty straightforward though and
encourage folks who want this to implement it. It can be implemented
as a separate package, although I wouldn't object to eventually
incorporating it into zope.configuration.
Jim
--
Jim Fulton
Zope Corporation
___
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 )
[Zope-dev] Re: zcml entry points
Tres Seaver wrote: I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. I think that the library vs. pluggable application distinction is valid here: maybe you want to define an entry point in the egg which a given pluggable app would use at startup time to configure all the plugins which exposed that entry point. +1 Five fakes such an entry point now by implicitly loading meta.zcml, then configure.zcml, then overrides.zcml for all packages it recognizes as products: are you proposing to replace Five's DWIM with a new, explicit version? That may be preferable, but quite hard from a BBB perspective. Right now all kinds of products exist that just expect their ZCML to be automagically loaded. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] Re: Schedule for Zope 2.11
Is there any reason that the pytz import is not required? I would like to add support for conversion to timezone aware datetimes, and would like to rely on pytz being available. I believe that pytz ships with Zope 2.11. When I wrote my patch, it was designed to work with older versions of Zope that don't ship with pytz. That's why I didn't assume that pytz was available. -Amos ___ 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 )
Re: [Zope-dev] zcml entry points
Hi. I can also see potential uses for this. Hopefully the utility will implemented as a zpl package so that it may eventually make it into zope.configuration. Many thanks. Regards, David Jim Fulton wrote: I understand that some folks would fine something like this to be very useful. I can especially see the benefit for pluggable apps, like Plone and Zope 2.. I support this idea. I would almost certainly not use it myself and can't justify my time to implement this. I think the implementation is pretty straightforward though and encourage folks who want this to implement it. It can be implemented as a separate package, although I wouldn't object to eventually incorporating it into zope.configuration. Jim -- Jim Fulton Zope Corporation ___ 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 ) ___ 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 )
Re: [Zope-dev] Re: zcml entry points
On Oct 18, 2007, at 8:17 AM, Tres Seaver wrote: I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. I think that the library vs. pluggable application distinction is valid here: maybe you want to define an entry point in the egg which a given pluggable app would use at startup time to configure all the plugins which exposed that entry point. This probably an indication that there are two (I know, that horrible number) types of packages: - packages which provide zcml sugar in the form of new directive definitions - packages which perform component registrations It seems that packages which do only the former could be classified as a true library while the latter is more application-y. It seems like in a perfect world, libraries should not need any configure.zcml, just a meta.zcml which contains little except meta directives. Personally I think it would be more useful to remove policy-laden registrations from existing packages so they're more libraryish and move these registrations into site.zcml (or an entry point moral equivalent) than it would be to attempt to annoint the status quo as the right thing by implementing dependency graph traversal. - C ___ 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 )
Re: [Zope-dev] Re: Schedule for Zope 2.11
--On 18. Oktober 2007 09:52:25 -0400 Amos Latteier [EMAIL PROTECTED] wrote: Is there any reason that the pytz import is not required? I would like to add support for conversion to timezone aware datetimes, and would like to rely on pytz being available. I believe that pytz ships with Zope 2.11. When I wrote my patch, it was designed to work with older versions of Zope that don't ship with pytz. That's why I didn't assume that pytz was available. Please clean up the code on the trunk. Since pytz is always available we don't need the try..except magic. Andreas pgpbup7DSq9iS.pgp Description: PGP signature ___ 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 )
[Zope-dev] Re: zcml entry points
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. I think that the library vs. pluggable application distinction is valid here: maybe you want to define an entry point in the egg which a given pluggable app would use at startup time to configure all the plugins which exposed that entry point. +1 Five fakes such an entry point now by implicitly loading meta.zcml, then configure.zcml, then overrides.zcml for all packages it recognizes as products: are you proposing to replace Five's DWIM with a new, explicit version? That may be preferable, but quite hard from a BBB perspective. Right now all kinds of products exist that just expect their ZCML to be automagically loaded. I'm not arguing against preserving the majyk done for things Zope2 calls 'Products'; however, I don't want to extend the majyk any further. I would also be fine with adding a new directive which caused explicit triggering of introspected ZCML, e.g.: !-- Load ZCML from all packages which register a 'meta.zcml' entry point -- majyk entry_point=meta.zcml / !-- Load ZCML from all packages which register a 'configure.zcml' entry point -- majyk entry_point=configure.zcml / I *really* don't see the point, by the way, in automagically running 'overrides.zcml' from products: by definition, the reusable package author doesn't know enough to override declarations made by other reusable packages. If a site manager wants to configure overides, then adding them manually to her site.zcml should be fine. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHF5mM+gerLs4ltQ4RAu1+AJ0RtIXJaedfzgEXbL+5cjYDNJI+rQCfRCtY 9DqQBllKGsr7wMAjVW6WQWA= =Yl5B -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] Re: Schedule for Zope 2.11
On 10/18/07, Andreas Jung [EMAIL PROTECTED] wrote: Please clean up the code on the trunk. Since pytz is always available we don't need the try..except magic. Done. -Amos ___ 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 )
Re: [Zope-dev] zope.sendmail parallelism branch
Benji York wrote: I've created a branch of zope.sendmail Doh! I created the branch and then committed my changes to the trunk. I'm too lazy to correct this unless someone really wants me to. -- Benji York Senior Software Engineer Zope Corporation ___ 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 )
[Zope-dev] Re: zope.app.error 3.5.1 not listed on distribution list
Uli Fouquet wrote: during grok development we recently experienced some trouble with the zope.app.error package. We distribute the list on `http://download.zope.org/distribution` as sources list for grokproject, so that projects created with that tool, by default lookup this list for available eggs/packages. Actually, what happens is that buildout/setuptools will go there for *extra* links. It will always go to the package index first. On this list the 3.5.1 release of zope.app.error is missing (older releases are available), which makes projects created with grokproject using an older release of zope.app.error, which in turn leads to errors. A bit annoying. This can't be the reason for buildout using an older version. buildout should by default go to the simple PyPI index, which clearly has zope.app.error 3.5.1 http://pypi.python.org/simple/zope.app.error. To understand the sources lookup process better, I would like to know: Is there a special reason, why zope.app.error 3.5.1 is not listed on the above distribution list (while older versions are listed)? I don't think we should continue uploading stuff to http://download.zope.org/distribution. What is the recommended sources list for looking up zope eggs during buildout, anyway? I wish we wouldn't have to specify http://download.zope.org/distribution at all in our buildout.cfg. I think we're close to this point. There is at least also the `ppix` 'listing' on download.zope.org (which already provides zope.app.error 3.5.1). What's the difference in terms of completeness and up-to-dateness of listed packages? http://download.zope.org/distribution is just a flat directory that svn committers can upload files to. It's used by buildout/setuptools as a find-links parameters. ppix is a *package index*, a mirror of the simple PyPI index to be precise. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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 )
[Zope-dev] zope.app.error 3.5.1 not listed on distribution list
Hi there, during grok development we recently experienced some trouble with the zope.app.error package. We distribute the list on `http://download.zope.org/distribution` as sources list for grokproject, so that projects created with that tool, by default lookup this list for available eggs/packages. On this list the 3.5.1 release of zope.app.error is missing (older releases are available), which makes projects created with grokproject using an older release of zope.app.error, which in turn leads to errors. A bit annoying. To understand the sources lookup process better, I would like to know: Is there a special reason, why zope.app.error 3.5.1 is not listed on the above distribution list (while older versions are listed)? What is the recommended sources list for looking up zope eggs during buildout, anyway? There is at least also the `ppix` 'listing' on download.zope.org (which already provides zope.app.error 3.5.1). What's the difference in terms of completeness and up-to-dateness of listed packages? Sorry, if this are dumb questions and thanks in advance, -- Uli ___ 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 )
[Zope-dev] Re: zope.app.error 3.5.1 not listed on distribution list
Hi Philipp, Philipp von Weitershausen wrote: Uli Fouquet wrote: during grok development we recently experienced some trouble with the zope.app.error package. We distribute the list on `http://download.zope.org/distribution` as sources list for grokproject, so that projects created with that tool, by default lookup this list for available eggs/packages. Actually, what happens is that buildout/setuptools will go there for *extra* links. It will always go to the package index first. I checked that and, yes, you are right. Anyway, your hint helped me to find the real reason, a misconfigured versions list of the grok release. Sorry for the trouble. Is there a special reason, why zope.app.error 3.5.1 is not listed on the above distribution list (while older versions are listed)? I don't think we should continue uploading stuff to http://download.zope.org/distribution. What is the recommended sources list for looking up zope eggs during buildout, anyway? I wish we wouldn't have to specify http://download.zope.org/distribution at all in our buildout.cfg. I think we're close to this point. Why do we have to? There is at least also the `ppix` 'listing' on download.zope.org (which already provides zope.app.error 3.5.1). What's the difference in terms of completeness and up-to-dateness of listed packages? http://download.zope.org/distribution is just a flat directory that svn committers can upload files to. It's used by buildout/setuptools as a find-links parameters. ppix is a *package index*, a mirror of the simple PyPI index to be precise. This sounds like a pretty complete and automatically up-to-date 'list', compared to the `distribution` list. Wouldn't it be useful then to set the index to ppix and drop the find-links entry? Thanks for the enlightenment! -- Uli ___ 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 )
