help from zope argentina
How are you Iam migration from zope 2.7.0 to 2.7.3 but when I run zope I have these error File "/root/raec/instance/lib/python/OFS/Application.py, line 405 in install_tempfolder_and_sdc period_secs=period_spec TypeError:__init__() got an unexpected keywork argument ' period_secs? Could you help me.. thanks gus
How did you do this migration? It sounds like you've got a mixture of old and new files in your Zope software directory. I'm not sure how this happened, but I doubt any of us can help you get to a sane state from there. So, to migrate: Make sure you install a fresh copy of Zope 2.7.3 in its own set of directories (instance home and software home). Copy Data.fs, Products, and any External methods you have from your old Zope instance to the new Zope instance. Start the new Zope instance. Is this what you did? - C On Wed, 2004-11-17 at 15:59 -0300, gus wrote:
How are you Iam migration from zope 2.7.0 to 2.7.3 but when I run zope
I have these error File "/root/raec/instance/lib/python/OFS/Application.py, line 405 in install_tempfolder_and_sdc period_secs=period_spec TypeError:__init__() got an unexpected keywork argument ' period_secs?
Could you help me.. thanks gus
_______________________________________________ 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 )
[ Chris McDonough <chrism@plope.com> ]: --------------------------------------------------------
So, to migrate: Make sure you install a fresh copy of Zope 2.7.3 in its own set of directories (instance home and software home). Copy Data.fs, Products, and any External methods you have from your old Zope instance to the new Zope instance.
Hi, that comment inspired the following observation: In zope.conf we can specify an out-of-Zope-tree directory for Products. # Directive: products # products /home/chrism/projects/myproducts I believe the 'Extensions' direcrectory deserves the same rights, or is there a good reason (that eludes me) for not having such a feature ? best regards, Rod Senra
On Thu, 18 Nov 2004 10:17:52 -0200, Rodrigo Dias Arruda Senra <rodsenra@gpr.com.br> wrote:
I believe the 'Extensions' direcrectory deserves the same rights, or is there a good reason (that eludes me) for not having such a feature ?
As I understand the Extensions directory, there's currently only support for one such directory for an instance; it's not a search path at all. For products, it *is* a search path, and the paths specified by the "products" configuration field are added to that search path (you can specify more than one in the configuration by including more than one "products" line in zope.conf). There's no way to *remove* the <instance>/Products directory. Whether or not Extensions should be a search path instead of a directory, I don't know. It doesn't seem entirely unreasonable, but a patch for Zope 2.8 would make it much more likely to happen. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> Zope Corporation
[ Fred Drake ]: ---------------
As I understand the Extensions directory, there's currently only support for one such directory for an instance; it's not a search path at all. For products, it *is* a search path, and the paths specified by the "products" configuration field are added to that search path (you can specify more than one in the configuration by including more than one "products" line in zope.conf). There's no way to *remove* the <instance>/Products directory.
Thanks for the explanation Fred. [ Andreas Jung ]: -----------------
-1. Sounds like a YAGNI to me. Not everything is could be made possible should be made possible just because it is need by one person. At least I have not seen a solid usecase for this...we have other problems to solve and bugs to fix :-)
[ Chris McDonough ]: --------------------
The need is one where you have multiple Zope instances that need to share a set of external methods. Currently you need to either put them in the software home Extensions or symlink the each of the instance home extensions directories to a common path.
In addition to Chris' comment, this happens every time I need to upgrade Zope. Even if you usually *play* single-instance Zope, while upgrading versions (Zope as a whole) it would be handy to have both instances (production and production-wannabe) sharing the same setup. I do not know if this is considered a "solid" use case though. <wink>
I'm not going to do any work on this, but I could see why someone would want it.
Neither would I ask you, nor Fred, nor Andreas for doing it. Afterall, I can live with ln or cp indefinetely longer. However, if people consider it NYAGNI I might try to cook up a 2.8 patch just for my own educational's sake. best regards, Rod Senra
On Thu, 2004-11-18 at 10:17 -0200, Rodrigo Dias Arruda Senra wrote:
[ Chris McDonough <chrism@plope.com> ]: --------------------------------------------------------
So, to migrate: Make sure you install a fresh copy of Zope 2.7.3 in its own set of directories (instance home and software home). Copy Data.fs, Products, and any External methods you have from your old Zope instance to the new Zope instance.
Hi,
that comment inspired the following observation:
In zope.conf we can specify an out-of-Zope-tree directory for Products.
# Directive: products # products /home/chrism/projects/myproducts
I believe the 'Extensions' direcrectory deserves the same rights, or is there a good reason (that eludes me) for not having such a feature ?
No, that's a good idea. I think I even started to make this possible once but ran out of time. Maybe it's worth a Collector issue? - C
--On Donnerstag, 18. November 2004 10:20 Uhr -0500 Chris McDonough <chrism@plope.com> wrote:
I believe the 'Extensions' direcrectory deserves the same rights, or is there a good reason (that eludes me) for not having such a feature ?
No, that's a good idea. I think I even started to make this possible once but ran out of time. Maybe it's worth a Collector issue?
-1. Sounds like a YAGNI to me. Not everything is could be made possible should be made possible just because it is need by one person. At least I have not seen a solid usecase for this...we have other problems to solve and bugs to fix :-) -aj
On Thu, 2004-11-18 at 16:30 +0100, Andreas Jung wrote:
--On Donnerstag, 18. November 2004 10:20 Uhr -0500 Chris McDonough <chrism@plope.com> wrote:
I believe the 'Extensions' direcrectory deserves the same rights, or is there a good reason (that eludes me) for not having such a feature ?
No, that's a good idea. I think I even started to make this possible once but ran out of time. Maybe it's worth a Collector issue?
-1. Sounds like a YAGNI to me. Not everything is could be made possible should be made possible just because it is need by one person. At least I have not seen a solid usecase for this...we have other problems to solve and bugs to fix :-)
The need is one where you have multiple Zope instances that need to share a set of external methods. Currently you need to either put them in the software home Extensions or symlink the each of the instance home extensions directories to a common path. I'm not going to do any work on this, but I could see why someone would want it. - C
--On Donnerstag, 18. November 2004 10:40 Uhr -0500 Chris McDonough <chrism@plope.com> wrote:
The need is one where you have multiple Zope instances that need to share a set of external methods. Currently you need to either put them in the software home Extensions or symlink the each of the instance home extensions directories to a common path.
I'm not going to do any work on this, but I could see why someone would want it.
In this case I would put the stuff in a fake product like $INSTANCE_HOME/MyFakeProduct/Extensions/... Such a product can be put under revision control and reused in different instances. That is a much cleaner solution than linking or copying files around. -aj
Andreas Jung wrote:
--On Donnerstag, 18. November 2004 10:40 Uhr -0500 Chris McDonough <chrism@plope.com> wrote:
The need is one where you have multiple Zope instances that need to share a set of external methods. Currently you need to either put them in the software home Extensions or symlink the each of the instance home extensions directories to a common path.
I'm not going to do any work on this, but I could see why someone would want it.
In this case I would put the stuff in a fake product like $INSTANCE_HOME/MyFakeProduct/Extensions/...
Such a product can be put under revision control and reused in different instances. That is a much cleaner solution than linking or copying files around.
-1 to requiring the creation fake product, which is a (fairly painful) workaround (e.g., you have to know to add an __init__.py to the product, and you have to know about the "funny" syntax for pointing an EM at the product-specific file). "Patches accepted" is the right response for the feature request here. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
[ Tres Seaver ]: ---------------- | "Patches accepted" is the right response for the feature request here. In this case I'm on it. Since it is my first patch to Zope, some advice is more than welcomed. The changes so far relative to svn truck are: * /lib/python/Products/ExternalMethod/help/ExternalMethod.py - docstring comment * /lib/python/Products/ExternalMethod/ExternalMethod.py - little typos (not related, but since I was there <wink>) - docstring comment * /etc/zope.conf - new directive 'extensions', comments and example * /lib/python/Zope/Startup/zopeschema.xml - new directive 'extensions' (type key) * /lib/python/App/Extensions.py - in getPath() check if directive 'extensions' is overriden in zope.conf, and use it instead. The relevant code added to getPath() is depicted below. <code> if (prefix=="Extensions") and (cfg.extensions is not None): r=_getPath(cfg.extensions, '', name, suffixes) if r is not None: return r </code> However, I did not understood the purpose of the construction "if r is not None: return r". That was the last statement in getPath(). If r==None then getPath() wouldn't return None all the same ? I believe this is the last bit of doubt before submitting the patch. BTW, maybe I should have posted this to Zope-Dev instead ? best regards, Senra
On Thu, 18 Nov 2004 17:25:11 -0200 Rodrigo Senra <rodsenra@gpr.com.br> wrote about Re: [Zope] Re: Give 'Extensions' a configurable directory in zope.conf: -------------------------------------------- | [ Tres Seaver ]: | ---------------- | | "Patches accepted" is the right response for the feature request here. | | In this case I'm on it. | ... before submitting the patch. Well, I could not resist so I submitted the patch. <wink> Issue 1584 title: Add 'extensions' directive in zope.conf regards, Senra
* /lib/python/Products/ExternalMethod/ExternalMethod.py
- little typos (not related, but since I was there <wink>)
It's a good practice to fix typos and such in a separate patch/checkin, so that those reading the diffs or patches can concentrate on what's really done.
* /lib/python/App/Extensions.py
- in getPath() check if directive 'extensions' is overriden in zope.conf, and use it instead.
The relevant code added to getPath() is depicted below.
<code> if (prefix=="Extensions") and (cfg.extensions is not None): r=_getPath(cfg.extensions, '', name, suffixes) if r is not None: return r </code>
It's also nice to use modern python coding style (even when copy/pasting code): if prefix == "Extensions" and cfg.extensions is not None: r = _getPath(cfg.extensions, '', name, suffixes) if r is not None: return r
However, I did not understood the purpose of the construction "if r is not None: return r".
That was the last statement in getPath(). If r==None then getPath() wouldn't return None all the same ?
It's in a loop. The first working path is returned.
I believe this is the last bit of doubt before submitting the patch.
BTW, maybe I should have posted this to Zope-Dev instead ?
Yep :) I Cc zope-dev, and followup there. But now that you put it in the collector it's ok. Thanks for the patch. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
participants (8)
-
Andreas Jung -
Chris McDonough -
Florent Guillaume -
Fred Drake -
gus -
Rodrigo Dias Arruda Senra -
Rodrigo Senra
-
Tres Seaver