Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> Daniel Nouri wrote:
>>> shurik writes:
>>>
>>>> I ran buildout and received the following error. Could anyone suggest what
>>>> the error might mean?
>>>>
>>>> While:
>>>> Installing instance.
>>>>
>>>> An internal error occured due to a bug in either zc.buildout or in a
>>>> recipe being used:
>>>>
>>>> UnknownExtra:
>>>> zope.component 0.0 has no such extra feature 'zcml'
>>> It turns out that this error is caused by recent changes in
>>> plone.z3cform. You need to make a small changes to your buildout
>>> configuration to fix this. Add these these lines to your
>>> ``fakezope2eggs`` or ``zope2`` section, depending on whether you're
>>> still using ``fakezope2eggs`` or not:
>>>
>>> skip-fake-eggs =
>>> zope.testing
>>> zope.component
>>> zope.i18n
>>>
>>> I've updated the plone.z3cform How-To on plone.org:
>>>
http://plone.org/documentation/how-to/easy-forms-with-plone3>> I'm a bit unhappy about this change to plone.z3cform. It means that
>> anyone wanting to use it must demand non-trivial changes to people's
>> buildouts. I realise to a certain extent it already did this by
>> requiring fakezope2eggs, but this is quite scary.
>>
>> I really think the "standard" release of plone.z3cform needs to work
>> with "standard" Zope 2.10.x and Plone 3.x if it is to have any chance of
>> being generally acceptable and usable.
>
> FWIW I disagree. This is the future, as is z3cform. We need to start
> preparing for that, and now is as good a time as any to start biting
> that bullet. As ChrisM said in another thread: any egg which does not
> declares its dependencies properly should be considered broken.
>
> If you're l33t enough to want to play with plone.z3cform this should not
> be a problem.
I may want to distribute a package that uses z3c.form. If I am to work
on improving z3c.form integration in Plone, then that's almost certainly
going to be the reason.
As of yesterday, distributing a generic package becomes hard and
fragile. It won't work for non-buildout uses probably, and it won't work
with anyone's standard buildout. It's hard to document what changes you
may need to do, especially if your buildout is not bog standard to begin
with.
That, and who knows what subtle conflicts we may see from using a
version of zope.component that's untested with the version of Zope
2.10.x that we're using?
This is why I think targeted backporting monkeypatches are a more
outwardly friendly solution in the short term. It is obviously more
painful to do from our side, and needs to be done very carefully, but it
increases the chance that people will be able to use (and thus evolve)
the z3c.form integration story.
In the medium term, I completely agree. This needs fixing at the Zope 2
level, and this is a good opportunity to start the fixing.
However, we may end up in a catch 22 situation here: People don't start
using z3c.form because it's too fragile to depend on the distribution
mechanism, and so we don't get around to fixing the underlying problems
(or we invest undue time in other things that could've been better spent
improving the z3c.form integration story if people believed it would be
a safe thing to depend on).
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See
http://martinaspeli.net/plone-book-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users
Locked
