Plone 3 buildout merged into 2.5 buildout

6 views
Skip to first unread message

Maurits van Rees

unread,
Nov 30, 2007, 10:55:28 PM11/30/07
to Get Paid Devs
Hi everyone,


This has turned out as a rather long email. So here is the summary:

- The buildout for Plone 3.0 has been deprecated.

- Instead the trunk buildout handles everything, so it is recommended
to use that for both 2.5 and 3.0 from now on.

- For 3.0 run: bin/buildout -c 30.cfg

- Make a backup of your buildout (especially var/filestorage/Data.fs
of course) before trying anything. Safety first.

- Don't like buildout? Try the latest nighly build:
http://getpaid.googlecode.com/files/PloneGetPaid-bundle-2007-12-01.tgz
and read the included README.txt.


Problem and possibility
-----------------------

Talking with Christopher on irc today I realized two things:

1. The way the nightly build for 2.5 was created, could lead to
problems. I knew this was the case for 3.0, but now also for 2.5.
Take the five.intid package. The build puts this in
PloneGetPaid/lib/five/intid. When you now add another five
package in your zope instance, so let's say
$INSTANCE_HOME/lib/python/five/localsitemanager, you cannot start
zope anymore. You will run into this error:

ConfigurationError: ('Invalid value for', 'package',
'ImportError: Module five has no global intid')

2. The differences between the 2.5 and 3.0 buildouts were not very
big. On 3.0 you need of course a different Plone and Zope version.
And you must not use a special Five version and also not CMFonFive.


Work done
---------

So I went to work on making one buildout that works on both 2.5 and
3.0. I have that working now. Instead of the separate 3.0 buildout
you can now use the normal buildout. But for Plone 3.0 you must not
simply do a bin/buildout, but this:

bin/buildout -c 30.cfg

That loads the config file for Plone 3.0, which extends the default
buildout.cfg that is used for 2.5.

I deprecated the 3.0 buildout by placing a text file with a warning in
it. The buildout still works fine and we need not immediately remove
it. We might even need it in the future, though we could also make a
fresh copy from the trunk buildout then. But personally I recommend
using the trunk buildout now for both 2.5 and 3.0.


Nightly build
-------------

After initial problems I uploaded my first nighly build:
http://getpaid.googlecode.com/files/PloneGetPaid-bundle-2007-12-01.tgz

As you probably realize, this build is good for 2.5 and 3.0. The
included README.txt instructs 3.0 users to ignore the Five and
CMFonFive directories. If you know a clearer way to phrase this,
please change scripts/README.txt in the buildout.


Gotcha
------

There may be one gotcha. I removed CMFonFive from the
develop-products directory. Instead this is now managed in
buildout.cfg: it goes into the new parts/productcheckouts. The 30.cfg
overwrites this setting so for 3.0 that parts/productcheckouts is not
made (or remains empty).

This can be compared to what happened halfway through October when
develop-products/Five was given the same treatment. That gave
problems to some people. So the procedure here is: do an svn update
and manually remove develop-products/CMFonFive if it is still there.
Then you can run bin/buildout (with or without the '-c 30.cfg').

Note that parts/five has just been removed in favour of
parts/productdistros, where it is joined by the recent Plone Hotfix.
There is no need for a separate directory in parts/ for every product
tar ball.


Switch back to trunk
--------------------

When I switch my 30 buildout to trunk like this, then I run into
problems:

$ svn switch https://getpaid.googlecode.com/svn/trunk/getpaid.buildout
svn: Won't delete locally modified directory '.'
svn: Left locally modified or unversioned files
$ svn status
X develop-debug
X wiki
! .
~ develop-products
S EXTERNALS.txt
S bootstrap.py
S buildout.cfg
X src/hurry.workflow
...
X src/getpaid.googlecheckout
S src
S scripts
S THIS_BUILDOUT_IS_DEPRECATED.txt
S recipes
S readme.txt

Maybe it is too late at night for me, but I do not see how to solve
this. Well, the easiest and quite possibly best solution would be to
just make a fresh checkout of the trunk buildout and copy your
var/filestorage/Data.fs over.

On a side note, in trunk the var/ directory is in subversion. I think
this is not good. I want to remove it from subversion. It should be
a local directory, not managed by subversion. But I am not 100
percent sure that an svn update would then not destroy the contained
Data.fs of users. So I would rather not touch that. If you are more
confident, go ahead and remove it (after some testing).


Testing
-------

Please test the buildout and the tar ball. See if all the tests from
bin/test pass. And run the tests of the PloneGetPaid product:

bin/instance test -s Products.PloneGetPaid

Currently this gives me one failure btw:

'unicode' object has no attribute 'isnumber'

You may want to run those tests also before updating. Then make a
safety copy of your current buildout and especially your Data.fs
before you start testing. Any update always has a certain risk in
it. Now do an svn update and bin/buildout. Run the tests again. If
you feel like giving 3.0 a go, run "bin/buildout -c 30.cfg -v".
Remove develop-products/CMFonFive if it still exists. Then run the
tests again.

Please report problems to the list. Happy testing!

And thanks for reading all the way to the bottom. :)

--
Maurits van Rees | http://maurits.vanrees.org/ [NL]
Work | http://zestsoftware.nl/
"I am trapped in a Klein Bottle and can't get in."

Christopher Johnson

unread,
Dec 1, 2007, 10:19:21 AM12/1/07
to getpa...@googlegroups.com
Cool! Thanks, Maurits.

I have a question though (in anticipation of ways I can break it now ;)...

What happens if I run the buildout 2.5 style...then on a subsequent update, I run it 3.0 style? Is the 2.5 instance thrown out? Or does the 3.0 one run parallel to it?

Though this seems better from a sanity of code management perspective, it seems potentially error-prone. Just wonder what the consequences are :)

Thanks again!

-chris

www.ifpeople.net
t: 678-608-3408
130 Boulevard NE, #6
Atlanta, GA 30312

Maurits van Rees

unread,
Dec 1, 2007, 7:00:40 PM12/1/07
to getpa...@googlegroups.com
Hi Christopher and others,

On Sat, Dec 01, 2007 at 10:19:21AM -0500, Christopher Johnson wrote:
> Cool! Thanks, Maurits.
>
> I have a question though (in anticipation of ways I can break it now ;)...

Code can break ???

;-)

> What happens if I run the buildout 2.5 style...then on a subsequent update,
> I run it 3.0 style? Is the 2.5 instance thrown out? Or does the 3.0 one run
> parallel to it?

Anything that lives in the parts/ directory of any buildout can be
replaced at any time. Some recipes are a bit more conservative. For
example the infrae.subversion recipe (that we use for CMFonFive now
and for the testrecorder) respects local changes that you may have
made to those checkouts. But generally when running bin/buildout you
should expect that the complete parts directory gets removed.

Of course not everything gets removed and readded all the time;
especially removing and recreating the zope2 dir takes some time. So
this is only replaced when a new version is specified in the buildout.
Buildout keeps track of several things like that in a usually
invisible ".installed.cfg" file in the main buildout directory.

That is the theory.

In our case, the instance likely gets removed and replaced completely.
The plone and zope2 directories are removed and replaced by their new
versions (3.0.3 and 2.10.4). The productcheckouts directory is
removed as it contained CMFonFive which is not needed with Plone 3.
All this is totally fine. I just tried it and nothing bad happened
that I noticed.

I then reverted back to 2.5 by running a normal bin/buildout (so
without the "-c 30.cfg" part) and that went fine as well. Note that
this route (going back to a previous plone/zope version) is generally
not advisable. At least I can imagine that things can go wrong then,
especially when you have run a plone migration to 3.0 already. But
from a buildout point of view, you can run "bin/buildout -c 30.cfg"
and "bin/buildout" as often as you like and nothing bad will happen.

> Though this seems better from a sanity of code management perspective, it
> seems potentially error-prone. Just wonder what the consequences are :)

The only danger I see is when going from the original 3.0 buildout to
the 3.0 one integrated in trunk. This is what I indicated in my
original mail. The best way for that seems to be to just create a
fresh trunk buildout in a new directory and copy over your Data.fs.
This should be no problem really. In production, when you need to
move an instance to a new server or something this is exactly how you
would do that.

Still, making a backup before doing a bin/buildout is always a good
idea. :)

Cheers,

Christopher Johnson

unread,
Dec 2, 2007, 10:56:54 PM12/2/07
to getpa...@googlegroups.com
well, i couldn't resist trying...after all, the notion of potentially being able to switch between a plone 3.0 and 2.5 buildout was too tempting!

so i have a 2.5 buildout that was running fine, with various plone sites (all testing). haven't done any customizing of code locally (here). I decided to stop the instance, and switch buildouts. When I did the bin/buildout -c 30.cfg, I got an error. Since this gets long, I will summarize:
- I followed the advice of the error
- That got my buildout working, but the instance still won't run in 3.0.
- I went back to 2.5 and it seems fine.
- No 3.0 switch possible...

My buildout 3.0 error was:

Got zc.recipe.testrunner 1.0.0.
Uninstalling test-recorder.
Running uninstall recipe.
While:
  Installing.
  Uninstalling test-recorder.

An internal error occured due to a bug in either zc.buildout or in a
recipe being used:

ValueError:
In '/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/test-recorder/testrecorder/testrecorder.pyc':
local modifications detected while uninstalling 'test-recorder': Uninstall aborted!

Please check for local modifications and make sure these are checked
in.

If you sure that these modifications can be ignored, remove the
checkout manually:

  rm -rf /home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/test-recorder

Or if applicable, add the file to the 'svn:ignore' property of the
file's container directory.  Alternatively, add an ignore glob pattern
to your subversion client's 'global-ignores' configuration variable.

...........................
Seems like reasonable advice....so I followed it. I got through the buildout then, but the instance choked when I tried to start it up. It gave me the following looooong error:

2007-12-02 22:42:20 INFO Zope.ZCatalog Finished migration of indexes for Control_Panel/Products/DCWorkflow/Help/catalog
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/zope/configuration/xmlconfig.py:323: DeprecationWarning: zope.app.annotation has moved to zope.annotation. Import of zope.app.annotation will become unsupported in Zope 3.5
  __import__(arguments[0])
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/src/getpaid.core/src/getpaid/core/configure.zcml:54: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="getpaid.core.vocabularies.CreditCardTypes "
      name="getpaid.core.credit_card_types"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/src/getpaid.core/src/getpaid/core/configure.zcml:59: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="getpaid.core.vocabularies.AcceptedCreditCardTypes "
      name="getpaid.core.accepted_credit_card_types"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/interfaces.py:8: DeprecationWarning: zope.app.event.interfaces has moved to zope.lifecycleevent.interfaces. Import of zope.app.event.interfaces will become unsupported in Zope 3.5
  from zope.app.event.interfaces import IObjectEvent
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/interfaces.py:8: DeprecationWarning: IObjectEvent is deprecated. IObjectEvent has moved to zope.component.interfaces
  from zope.app.event.interfaces import IObjectEvent
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/zope/configuration/config.py:692: DeprecationWarning: The five:traversable statement is no longer needed and will be removed in Zope 2.12.
  actions = self.handler(context, **args)
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/zope/configuration/config.py:184: DeprecationWarning: zope.app.event.objectevent has moved to zope.lifecycleevent. Import of zope.app.event.objectevent will become unsupported in Zope 3.5
  mod = __import__(mname, *_import_chickens)
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/zope/configuration/config.py:199: DeprecationWarning: objectEventNotify is deprecated. It has moved to zope.component.event.  This reference will be gone in Zope 3.5
  obj = getattr(mod, oname)
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/configure.zcml:62: DeprecationWarning: The five:localsite directive is deprecated and will be removed in Zope 2.12.
See Five/doc/localsite.txt .
  <five:localsite
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/src/ore.viewlet/src/ore/viewlet/base.py:5: DeprecationWarning: zope.app.annotation.interfaces has moved to zope.annotation.interfaces. Import of zope.app.annotation.interfaces will become unsupported in Zope 3.5
  from zope.app.annotation.interfaces import IAnnotations
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/src/yoma.batching/src/yoma/batching/__init__.py:14: DeprecationWarning: zope.app.traversing has moved to zope.traversing. Import of zope.app.traversing will become unsupported in Zope 3.5
  from zope.app.traversing.browser import AbsoluteURL
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/src/yoma.batching/src/yoma/batching/__init__.py:14: DeprecationWarning: zope.app.traversing.browser has moved to zope.traversing.browser. Import of zope.app.traversing.browser will become unsupported in Zope 3.5
  from zope.app.traversing.browser import AbsoluteURL
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/browser/order.py:10: DeprecationWarning: FiveTraversable is deprecated. __bobo_traverse__ and ITraverser/ITraversable for controlling URL traversal have become obsolete. Use an IPublishTraverse adapter instead.  This reference will go away in Zope 2.12.
  from Products.Five.traversable import FiveTraversable
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/browser/order.py:17: DeprecationWarning: zope.app.traversing.interfaces has moved to zope.traversing.interfaces. Import of zope.app.traversing.interfaces will become unsupported in Zope 3.5
  from zope.app.traversing.interfaces import ITraversable
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/src/getpaid.core/src/getpaid/core/event.py:6: DeprecationWarning: ObjectEvent is deprecated. It has moved to zope.component.interfaces.  This reference will be gone in Zope 3.5.
  from zope.app.event.objectevent import ObjectEvent
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/zope/configuration/config.py:692: DeprecationWarning: The five:defaultViewable statement is no longer needed and will be removed in Zope 2.12.
 If you rely on it to make 'index.html' the default view, replace it with <browser:defaultView name='index.html' />
  actions = self.handler(context, **args)
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/vocabularies.zcml:7: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="Products.PloneGetPaid.vocabularies.ContentTypes "
      name="plone.content_types"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/vocabularies.zcml:13: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="Products.PloneGetPaid.vocabularies.PaymentMethods "
      name="getpaid.payment_methods"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/vocabularies.zcml:19: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="Products.PloneGetPaid.vocabularies.ShippingMethods "
      name="getpaid.shipping_methods"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/vocabularies.zcml:25: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="Products.PloneGetPaid.vocabularies.TaxMethods "
      name="getpaid.tax_methods"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/vocabularies.zcml:31: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="Products.PloneGetPaid.vocabularies.Currencies "
      name="getpaid.currencies"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/vocabularies.zcml:43: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="Products.PloneGetPaid.vocabularies.WeightUnits "
      name="getpaid.weight_units"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/vocabularies.zcml:48: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="Products.PloneGetPaid.vocabularies.MerchantNotificationChoices "
      name="getpaid.merchant_notification_choices"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/vocabularies.zcml:53: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="Products.PloneGetPaid.vocabularies.CustomerNotificationChoices "
      name="getpaid.customer_notification_choices"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/vocabularies.zcml:58: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="Products.PloneGetPaid.vocabularies.Countries "
      name="getpaid.countries"
      />
  <vocabulary
/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/vocabularies.zcml:63: DeprecationWarning: The 'vocabulary' directive has been deprecated and will be removed in Zope 3.5.  Use the 'utility' directive instead to register the class as a named utility:
  <utility
      provides="zope.schema.interfaces.IVocabularyFactory"
      component="Products.PloneGetPaid.vocabularies.States "
      name="getpaid.states"
      />
  <vocabulary
2007-12-02 22:42:32 ERROR Application Couldn't install Five
Traceback (most recent call last):
  File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/OFS/Application.py", line 786, in install_product
    initmethod(context)
  File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/Products/Five/__init__.py", line 28, in initialize
    zcml.load_site()
  File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/Products/Five/zcml.py", line 53, in load_site
    _context = xmlconfig.file(file)
  File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/zope/configuration/xmlconfig.py", line 581, in file
    context.execute_actions ()
  File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/zope/configuration/config.py", line 606, in execute_actions
    for action in resolveConflicts(self.actions):
  File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/zope/configuration/config.py", line 1513, in resolveConflicts
    raise ConfigurationConflictError(conflicts)
ConfigurationConflictError: Conflicting configuration actions
  For: ('browser', 'MenuItemType', u'object')
    File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/CMFonFive/configure.zcml", line 7.2-10.6
        <browser:menu
          id="object"
          title="Object menu"
          />
    File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/plone/CMFCore/browser/configure.zcml", line 43.2-46.6
        <browser:menu
          id="object"
          title="Object menu"
          />
  For: ('interface', u'zope.app.menus.object')
    File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/CMFonFive/configure.zcml", line 7.2-10.6
        <browser:menu
          id="object"
          title="Object menu"
          />
    File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/plone/CMFCore/browser/configure.zcml", line 43.2-46.6
        <browser:menu
          id="object"
          title="Object menu"
          />
  For: ('utility', <InterfaceClass zope.app.publisher.interfaces.browser.IBrowserMenu >, u'object')
    File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/CMFonFive/configure.zcml", line 7.2-10.6
        <browser:menu
          id="object"
          title="Object menu"
          />
    File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/plone/CMFCore/browser/configure.zcml", line 43.2-46.6
        <browser:menu
          id="object"
          title="Object menu"
          />
  For: ('view', (<InterfaceClass zope.app.form.interfaces.IWidgetInputError>, <InterfaceClass zope.publisher.interfaces.browser.IBrowserRequest >), u'', <InterfaceClass zope.app.form.browser.interfaces.IWidgetInputErrorView>)
    File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/eggs/plone.app.form-1.0.3-py2.4.egg/plone/app/form/overrides.zcml", line 7.2-13.8
        <view
            type="zope.publisher.interfaces.browser.IBrowserRequest"
            for="zope.app.form.interfaces.IWidgetInputError"
            provides="zope.app.form.browser.interfaces.IWidgetInputErrorView "
            factory=".exception.WidgetInputErrorView"
            permission="zope.Public"
            />
    File "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/PloneGetPaid/overrides.zcml", line 7.2-14.8
        <view
            zcml:condition="installed Products.CMFonFive"
            type="zope.publisher.interfaces.browser.IBrowserRequest"
            for="zope.app.form.interfaces.IWidgetInputError "
            provides="zope.app.form.browser.interfaces.IWidgetInputErrorView"
            factory=".browser.exception.WidgetInputErrorView"
            permission="zope.Public"
            />
> /home/cjohnson/software/getpaid/getpaid/getpaid.buildout/parts/zope2/lib/python/zope/configuration/config.py(1513)resolveConflicts()
-> raise ConfigurationConflictError(conflicts)

This email is getting long, so I pasted the traceback here: http://paste.plone.org/18273

I continued on my breaking binge and then tried to go back to Plone 2.5 with a normal buildout command. Happy to report that that seems to have worked fine :). Instance and plones still there and working...


-chris


Maurits van Rees

unread,
Dec 3, 2007, 5:06:30 AM12/3/07
to getpa...@googlegroups.com
On Sun, Dec 02, 2007 at 10:56:54PM -0500, Christopher Johnson wrote:
> DeprecationWarning: The 'vocabulary' directive has been deprecated and will
> be removed in Zope 3.5. Use the 'utility' directive instead to register the
> class as a named utility:
> <utility
> provides="zope.schema.interfaces.IVocabularyFactory"
> component="getpaid.core.vocabularies.CreditCardTypes"
> name="getpaid.core.credit_card_types"
> />
> <vocabulary

I tried avoiding this DeprecationWarning but could not get it to work
on both 2.5 and 3.0. So we will have to live with this warning on
zope startup for 3.0. :(

> 2007-12-02 22:42:32 ERROR Application Couldn't install Five

This is probably caused just by the CMFonFive error below.

> line 1513, in resolveConflicts
> raise ConfigurationConflictError(conflicts)
> ConfigurationConflictError: Conflicting configuration actions
> For: ('browser', 'MenuItemType', u'object')
> File
> "/home/cjohnson/software/getpaid/getpaid/getpaid.buildout/develop-products/CMFonFive/configure.zcml",
> line 7.2-10.6
> <browser:menu
> id="object"
> title="Object menu"
> />

You need to manually remove the develop-products/CMFonFive directory.
Unfortunately this is not something that buildout (or rather svn
update) does for you. That is the reason why I went for putting
CMFonFive in parts/productcheckouts/CMFonFive using a recipe, which is
easily ignored for 3.0.

You can safely remove develop-products/CMFonFive also on 2.5, because
it is in parts/productcheckouts already.

That Should Work (TM).

Reply all
Reply to author
Forward
0 new messages