Cannot create Plone site when S&D installed

Reported by Gilles Lenfant on 2008-07-30
6
Affects Status Importance Assigned to Milestone
Singing & Dancing
Undecided
Daniel Nouri

Bug Description

Hi,

I updated my buildout today with S&D and there's no way to create a new Plone site. This has been reproduced on a vanilla instance built with the buildout.cfg made by "paster create -t plone3_buildout" and following strictly the instructions in http://pypi.python.org/pypi/collective.dancing/0.5.0

The traceback when creating a new Plone site :

Traceback (innermost last):
  Module ZPublisher.Publish, line 119, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object
  Module Products.CMFPlone.factory, line 85, in addPloneSite
  Module Products.GenericSetup.tool, line 390, in runAllImportStepsFromProfile
   - __traceback_info__: profile-Products.CMFPlone:plone
  Module Products.GenericSetup.tool, line 1182, in _runImportStepsFromContext
  Module Products.GenericSetup.tool, line 1093, in _doRunImportStep
   - __traceback_info__: plone-archetypes
  Module Products.CMFPlone.setuphandlers, line 487, in importArchetypes
  Module Products.CMFPlone.setuphandlers, line 86, in installArchetypes
  Module Products.CMFQuickInstallerTool.QuickInstallerTool, line 470, in installProduct
   - __traceback_info__: ('CMFFormController',)
  Module Products.CMFQuickInstallerTool.QuickInstallerTool, line 391, in snapshotPortal
  Module five.localsitemanager.registry, line 176, in registeredUtilities
ValueError: too many values to unpack

Daniel Nouri (daniel.nouri) wrote :

I've seen this bug before. It's caused by recent changes in zope.component, which triggered a bug in five.localsitemanager. Please make sure you're using at least five.localsitemanager 0.4. See http://pypi.python.org/pypi/five.localsitemanager

Please reopen this bug should the error persist.

Changed in singing-dancing:
assignee: nobody → daniel.nouri
status: New → Fix Released
Gilles Lenfant (gilles-lenfant) wrote :

Hi,

The latest recipe "plone.recipe.plone" (3.1.4) installs explicitely five.localsitemanager-0.3-py2.4.egg. Changing manually this egg (and the "instance" script accordingly doen't change anything (exactly the same traceback)

I got exactly the same traceback.

Not really off topic, but hopefully, S&D is - hopefully - the only Plone extension I need that requires more recent component versions than the ones that ship with the Zope 2.10/Plone3.1 bundle, and I'm not really confident about the side effect that may result of this choice on the other components I'm including in my site (PloneArticle, Collage, Ploneboard, ...)

Gilles Lenfant (gilles-lenfant) wrote :

Sorry, I don't see (or search correctly) how to reopen this ticket. Please consider it reopened.

Gilles Lenfant (gilles-lenfant) wrote :

Found finally ;-)

Changed in singing-dancing:
status: Fix Released → New
Daniel Nouri (daniel.nouri) wrote :

Okay, this is annoying. I'm not sure I agree that plone.recipe.plone should require an exact version of five.localsitemanager.

In any event, I think this should fix it: In your [plone] section, override the version of localsitemanager that plone.recipe.plone uses with the latest bugfix release:

  [plone]
  recipe = plone.recipe.plone
  eggs =
    five.localsitemanager == 0.4

Please let me know if this fixes your problem.

Considering your concerns about using the latest zope.component; yes, I agree that generally, this can be problematic. But thankfully zope.component is a rather stable piece of software that hardly changes. I hope this version juggling will soon come to an end.

I tried to pin plone.z3cform to not use the latest zope.component in version 0.4 of plone.z3cform, because it the first zope.component 0.5 was really buggy, but then we found out that buildout isn't really intelligent enough with resolving dependencies:

  https://bugs.launchpad.net/zc.buildout/+bug/253260

So I moved plone.z3cform back to using the latest zope.component.

Daniel Nouri (daniel.nouri) wrote :

I was wrong about predicting how the plone.recipe.plone "eggs" parameter works.

Instead of

  [plone]
  recipe = plone.recipe.plone
  eggs =
    five.localsitemanager == 0.4

you should use:

  [plone]
  recipe = plone.recipe.plone
  eggs =
    five.localsitemanager

and in the eggs option in your [buildout] section, add:

  [buildout]
  ...
  eggs =
      ...
      five.localsitemanager == 0.4

I'm actively looking into making this more smooth.

Daniel Nouri (daniel.nouri) wrote :

Okay, so I just released a new version of plone.app.z3cform which requires zope.component <= 3.4.0

Upgrading your buildout without the -N option should fix this issue now, without the need to change your buildout like described above.

Gilles Lenfant (gilles-lenfant) wrote :

Triple hurray !!!

Excellent job Daniel.

Your comment # 5 raised a bug in plone.recipe.plone, which doc says... "... Alternatively, if you need to upgrade or downgrade a particular egg, you can do so with a version specification". I'll file this in the right place.

Close this ticket if I can't, I'll open others cause I love S&D ;o)

Changed in singing-dancing:
status: New → Fix Released
Malthe Borch (mborch) wrote :

I believe the correct approach to this (given zc.buildout's buggyness) is:

[buildout]
versions = versions

[versions]
zope.component = 3.4.0

Imposing artificial version-pegs in packages is not the right approach in my view.

Daniel Nouri (daniel.nouri) wrote :

Gilles, I'm glad it's working finally.

Malthe, I agree with what you're saying. But I'm a bit concerned about the usability of plone.app.z3cform here. You know that the use of plone.z3cform already requires a few special lines in buildout. I'd like to avoid complicating the installation instructions further.

As far as jbot is concerned, you'll probably want to use the versions feature of buildout, since creating a dependency on z.c == 3.4.0 in the package will more likely cause trouble, esp. with uses in non-Zope 2 installations, right?

2008/8/1 Daniel Nouri <email address hidden>:
> Malthe, I agree with what you're saying. But I'm a bit concerned about
> the usability of plone.app.z3cform here. You know that the use of
> plone.z3cform already requires a few special lines in buildout. I'd
> like to avoid complicating the installation instructions further.

I agree with this sentiment, on the other hand, it's crucial that
users know what [versions] is (I certainly didn't until recently, and
it's caused me much grief); maybe if it was "official best practice"
to know and peg versions, it would all be ok.

> As far as jbot is concerned, you'll probably want to use the versions
> feature of buildout, since creating a dependency on z.c == 3.4.0 in the
> package will more likely cause trouble, esp. with uses in non-Zope 2
> installations, right?

Right, it wouldn't make sense to peg it I think; otoh, I don't think
jbot has any users outside the Plone realm.

\malthe

Daniel Nouri (daniel.nouri) wrote :

Okay, so my change to plone.z3cform was undone. Which means that you'll have to use

    [buildout]
    ...
    versions = versions

    [versions]
    zope.component = 3.4

or use the option in plone.recipe.plone to override the five.localsitemanager version with the more recent version >= 0.4.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers