[Grok-dev] Entity Relations and Forms
faassen at startifact.com
Wed Jan 21 08:13:05 EST 2009
Jeroen Michiel wrote:
> It's indeed version 0.4.0 I got.
> I pinned it to 0.3.5 in versions.cfg and it works now. Perhaps this should
> be done in the official versions.cfg, or can't you do that because it's not
> needed for everyone? I'm not up to speed with buildout and pinned versions
> and stuff like that (yet).
I think we should seriously consider pinning it down in our buildout.cfg
(or at least make the most recent version work). It's possible to pin
something down that's not a direct dependency of Grok.
This brings up some issues about extension packages in general. Does
Grok want to start pinning down versions that it doesn't require? Or
should perhaps Grok start to require zc.sourcefactory just for the
convenience? And if we do, how do we test that it hasn't broken?
> I tried on a testproject to use the 0.4.0 of sourcefactory, but went from
> one error to another...
> I changed zope.app.form to version 3.7.0 as you suggested, and that indeed
> requires zop.schema>=3.5a1
> So I also changed that, but while starting up the server, I got this
> DeprecationWarning: ITerms is deprecated. It has moved t
> o zope.browser.interfaces This reference will be gone sometimes.
Yeah, this kind of warning is all right, though implies that
zope.configuration ought to be updated to a newer version that gets rid
of this dependency as well. It doesn't appear to have been, so perhaps
the dependency isn't correct. We've had a discussion on how to do
deprecation properly on zope-dev that gave me some ideas on how to
improve the current situation.
> Trying the add page dumped this error:
Which add page is this? Ah, the add page in your test app.
> line 95, in adapter_hook
> return siteinfo.adapter_hook(interface, object, name, default)
> line 38, in fromString
> return md5.md5(value).hexdigest()
> TypeError: new() argument 1 must be string or read-only buffer, not
Looks scary; it seems as if it's a result of trying to take a md5 sum
off something that isn't a string but an object in a container.
> So I figured perhaps the warning is a good hint, and I changed the
> zope.configuration to the latest version , being 3.4.1, but that did not
> remove the warning, or solve the error.
I wonder what's triggering this, there must be a source somewhere that
used to work but now for some reason fails to work. Could you post the
code of the source factory again?
> As the penultimate egg that was used in the error log was zop.app.component,
> I tried getting a later version for that one (3.5.0), although it didn't
> state anything in the changes log about this.
Looks like we need to completely review the versions that Grok requires
once we want to upgrade to a newer set. Thank goodness we're actually
pinning them down, it'd have been complete chaos if we didn't as new
dependencies of Grok get released.
Our new issue is how to handle extension packages of Zope 3/Grok that
people want to use. I think we need to start managing recommended
versions of these in our versions.cfg as well, so that they don't
install in a broken way like zc.sourcefactory has become. But we really
need to think of a way to sensibly test what works. Zope 3 has a way to
test packages in an integrated fashion that perhaps would flush out
problems like this.
More information about the Grok-dev