z3c.autoinclude does not automatically include a plone package

Something I stumbled over just recently and is a PEBKAC again. What happens if you create a plone package and you always need to explicitly specify the zcml slot for that package? Check the namespace declaration in the setup.py. That means, what I had configured:

 # -*- Entry points: -*-
 target = plone

But the packages layout was “mooball.portlets.latestcontent”. After digging, I found out that simply the namespace_package is incorrectly declared. Changing it to:

 namespace_packages=['mooball', 'mooball.portlets'],
 # -*- Entry points: -*-
 target = plone

… got it correctly included via z3c.autoinclude.


No such file or directory FakePlugin.egg-info

In case you run into a similar issue which ends up in a traceback like this:

ZopeXMLConfigurationError: File "/opt/works/projects/plone4/nuw.types/nuw/types/configure.zcml", line 12.2-12.37
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/mooball.plone.activecampaign-0.2-py2.7.egg/mooball/plone/activecampaign/configure.zcml", line 10.2-10.37
OSError: [Errno 2] No such file or directory: '/home/roman/tools/python2.7/lib/python2.7/site-packages/tests/fake_packages/FakePlugin.egg/FakePlugin.egg-info'

you might have made the same mistake then I did: install ZopeSkel in your (system-) python installation. Never do this. Mikko explains on his blog why.

So, check your python installation and uninstall/remove the PasteScript.

handleUidAnnotationEvent from Products.CMFUID throws AttributeError

I stumbled over a weird error during a package setup, which turned out a PEBCAC error. The full traceback:

File "/home/roman/.buildout/eggs/zope.interface-3.6.3-py2.6-linux-x86_64.egg/zope/interface/adapter.py", line 583, in subscribers
File "/home/roman/.buildout/eggs/Products.CMFUid-2.2.1-py2.6.egg/Products/CMFUid/UniqueIdAnnotationTool.py", line 86, in handleUidAnnotationEvent
AttributeError: 'NoneType' object has no attribute 'unregister'

I went throught my whole code and type setup unable to find the mistake I’ve made unless I saw the problem. I imported a configuration module for an ArcheTypes content type declaration from a separate package which was not declared in the setup.py of my new package, e.g.:

$ cat my.package.event.py
from separate.package.config import PROJECTNAME
from plone.directives.form import Schema

class IMyType(Schema): ...

If you stumble over this error, make sure your imports are sane.

Broken (Arche-)Type Installation in Tests

I’ve recently run into this issue, migrating some of the Plone 3 product code to Plone 4. Installing some of the old types in my tests ended in a

File "/projects/plone3/my.product/my/product/tests/test_users.py", line 19, in test_mycontent
self.portal.invokeFactory('GalleryFolder', 'spam', title='eggs')
File "/home/roman/.buildout/eggs/Products.CMFCore-2.2.4-py2.6.egg/Products/CMFCore/TypesTool.py", line 311, in constructInstance
raise AccessControl_Unauthorized('Cannot create %s' % self.getId())
Unauthorized: Cannot create GalleryFolder

Digging deeper I found out, that all of the product factories were gone. Any debugging finding the cause of this ended up in a nowhere, until I stumbled over some odd behavior. All my imports in the testing.py are sorted, e.g.:

from Products.CMFPlone.tests.utils import MockMailHost
from Products.MailHost.interfaces import IMailHost
from Products.SiteErrorLog.SiteErrorLog import SiteErrorLog
import zope.component

What I now found out by accident is, if you move the import of the MockMailHost to the end of the import block, your Archetypes types are installable again:

from Products.MailHost.interfaces import IMailHost
from Products.SiteErrorLog.SiteErrorLog import SiteErrorLog
import zope.component
from Products.CMFPlone.tests.utils import MockMailHost

I currently don’t know why, but if anyone had the time to check, I’d be happy to know.

AttributeError when Installing Custom Theme Package

If you’re creating a new Plone theme package based on plone.app.theming and run into the following error:

Traceback (innermost last):
  Module ZPublisher.Publish, line 126, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 46, in call_object
  Module Products.CMFQuickInstallerTool.QuickInstallerTool, line 575, in installProducts
  Module Products.CMFQuickInstallerTool.QuickInstallerTool, line 512, in installProduct
   - __traceback_info__: ('my.skin',)
  Module Products.GenericSetup.tool, line 323, in runAllImportStepsFromProfile
   - __traceback_info__: profile-my.skin:default
  Module Products.GenericSetup.tool, line 1080, in _runImportStepsFromContext
  Module Products.GenericSetup.tool, line 994, in _doRunImportStep
   - __traceback_info__: plone.app.theming
  Module plone.app.theming.exportimport.handler, line 40, in importTheme
  Module plone.app.theming.utils, line 427, in applyTheme
  Module plone.registry.recordsproxy, line 43, in __setattr__
AttributeError: currentTheme

This will probably have nothing to do with a wrong setup in your theme, but simply a dependency issue to diazo.
Just make sure you install “Diazo theme support” before your theme is installed.

Reference: http://plone.293351.n2.nabble.com/plone-app-theming-1-0b5-and-Plone-4-1rc2-Plone-4106-td6418670.html

Plone ConfigurationError hides missing configuration files

This one is a quicky. If you run into the following error:

    raise ConfigurationError("Unknown directive", ns, n)
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/opt/works/projects/plone4/apf.buildout/parts/instance/etc/site.zcml", line 16.2-16.23
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/Products.CMFPlone-4.1-py2.6.egg/Products/CMFPlone/configure.zcml", line 99.4-103.10
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/plone.app.dexterity-1.0.3-py2.6.egg/plone/app/dexterity/configure.zcml", line 16.4-16.52
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/plone.directives.dexterity-1.0.2-py2.6.egg/plone/directives/dexterity/configure.zcml", line 3.4-3.35
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/five.grok-1.2.0-py2.6.egg/five/grok/configure.zcml", line 15.2-15.40
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/grokcore.viewlet-1.8-py2.6.egg/grokcore/viewlet/configure.zcml", line 7.2-7.44
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/zope.contentprovider-3.7.2-py2.6.egg/zope/contentprovider/configure.zcml", line 12.4
ConfigurationError: ('Unknown directive', u'http://namespaces.zope.org/tales', u'expressiontype')

… and you are using plone.app.theming and dexterity you will want to
check your buildout configuration file.
Make sure you have the dependent configuration files included:

extends =

The above configurations can change with future plone releases.

Buildout Entry ‘default’ missing?

I recently ran into the following issue with a Plone 3.3.4 buildout:

  Getting section instance.
  Initializing section instance.
  Loading zc.buildout recipe entry plone.recipe.zope2instance:default.

An internal error occured due to a bug in
either zc.buildout or in a recipe being used:
Traceback (most recent call last):
  File "/home/roman/.buildout/eggs/
        line 1009, in _install_and_load
    return pkg_resources.load_entry_point(
  File "build/bdist.linux-x86_64/egg/pkg_resources.py",
        line 305, in load_entry_point
  File "build/bdist.linux-x86_64/egg/pkg_resources.py",
        line 2243, in load_entry_point
ImportError: Entry point ('zc.buildout', 'default') not found

I tried to recompile my python 2.4 (because the OS was just newly installed and my lack on a few dev libraries), pin to different buildout versions but couldn’t figure out what was wrong in the finish.

What I ended up doing in the finish, was:

  1. remove my shared buildout directory (e.g. $HOME/.buildout)
  2. rerun a buildout, which created the eggs directory in the buildout directory which seem to work fine
  3. canceled the local buildout run,
  4. recreated the shared buildout directory with my default configuration (e.g. $HOME/.buildout, $HOME/.buildout/default.cfg and $HOME/.buildout/eggs)
  5. rerun the buildout now using the global eggs directory (e.g. $HOME/.buildout/eggs)

Another thing which I’ve noticed, is that zc.buildout does not have a ‘default’ entry point. I checked releases of zc.buildout back to 1.0. I wonder why it seems to be so arbitrarily being loaded that it works sometimes and sometimes not.

Ah … and btw. always a good one: Sometimes removing the .installed.cfg (it’s hidden with a dot in front!) helps as well.