heads-up: watch out for dependencies on “Plone”
Watch out if you’re installing an add-on product to a Plone 3.1.x site that declares a dependency on “Plone” in its setup.py. Plone wasn’t packaged as an egg until Plone 3.2.x, so this will result in buildout trying to pull in the latest Plone on top of the one you’ve already got via the plone.recipe.plone recipe, and you’ll see a VersionConflictError.
I just helped someone on #plone who ran into this with the collective.flowplayer product. If you’re sure the product is actually compatible with Plone 3.1.x, you can work around this by adding “Plone” to the additional-fake-eggs option of the plone.recipe.zope2install buildout section.
I am proof of success:
[zope2]
additional-fake-eggs =
Plone = 3.1.4
Carlos Hanson said this on March 6th, 2009 at 4:47 pm
good one, i was wondering how to make packages compatible for both 3.1 and 3.2
Rok Garbas said this on March 6th, 2009 at 5:23 pm
I just released a new version of collective.flowplayer that doesn’t depend on Plone. I should probably have waited until eggified Plone had been out for a couple releases before doing that.
Ross Patterson said this on March 6th, 2009 at 10:14 pm
Want my opinion?
Plone is already SO difficult, and with these mistakes, developers are making it impossible to use!! I’ve lost a week with this error!!!!
Shame on you, developer of “flowplayer”!!
Jorge.
Jorge said this on March 7th, 2009 at 5:56 am
Jorge, that’s too bad about the lost time. But mistakes happen, and I tend to think Ross deserves our kudos for fixing the error and making a new release within five hours of when the problem was identified, without (to my knowledge) being directly prompted to do so. Thanks, Ross!
Of course, hindsight is 20/20, but it’s always a wise idea to have a backup of your site before installing a new add-on product — this is true for any system.
Better luck next time!
davisagli said this on March 7th, 2009 at 9:28 am