[Grok-dev] megrok.form errors

[Lacko Roman]

Thank You Martijn,

I will wait for new release of megrok.form

Regards
- Roman Lacko

-----Original Message-----
From: grok-dev-bounces at zope.org [mailto:grok-dev-bounces at zope.org] On Behalf Of Martijn Faassen
Sent: Thursday, April 24, 2008 1:15 AM
To: grok-dev at zope.org
Subject: [Grok-dev] megrok.form errors

Hi there,

Thanks for the report - this exactly the kind of feedback we need to
track down problems.

Lacko Roman wrote:
 > Sorri, forget to say, a put one extra requirement into setup.py:
 >         ...
 >         # Add extra requirements here
 >         'megrok.form',
 >         ...
[snip useful conflict error traceback]
 > But When I removed zcml instruction "<includeDependencies package="." />"
 > from src\klucsite\configure.zcml Zope started successfully

The odd thing is that I tested exactly the megrok.form scenario before
the release (and just now again), so now I'm wondering what went
wrong... Ah, I think I figured it out, see below.

I just reproduced it! Your conflict error messages luckily had the
versions of the eggs you were using, and I noticed that my eggs have
different versions...

I was using the ugly version zc.datetimewidget 0.6.1dev-r72453. You were
using a more proper release, 0.5.2. I don't know where I got 0.6.1dev
from, probably got it somewhere long ago, as it doesn't seem to appear
on PyPI. When I made 0.5.2 a requirement, I got the same error.

When I remove the auto-inclusion and put in this instead (which is what
the includeDependencies directive actually does):

<include package="megrok.form" />

...I get the same error. So this doesn't appear to be triggered by
auto-inclusion, but is seems to be a problem with megrok.form.

The strange thing is that 0.5.2 *is* the latest public release and it's
months old, so I'm rather confused as to why nobody ran into this one
before. Dirceu, what version of megrok.form are you using for
developing? Anyway, the fix appears to be that megrok.form is doing a
registration that zc.datetimewidget is *also* doing, so Dirceu should be
able to fix this one easily.

Anyway, if I'm right, that concludes this immediate question: I
recommend to you wait until Dirceu makes a new release with the fix.
It's not a 0.12 problem, it's not an auto-inclusion problem, but it
appears to be a megrok.form problem.

Now on to the wider problem this demonstrates, for everybody to think
about, and for Dirceu in particular:

All this is again a good argument for version pinning. If Dirceu would
somehow supply exactly the versions *he* is using to all users of
megrok.form, then everybody would either get the same error, or none at all.

We currently pin the packages that Grok depends on directly, but we
don't pin down the extra packages that megrok.form depends on. Perhaps
we should start pinning down all the versions of possible Grok
dependencies too, but that'll have to wait until we figure out how: see
whether we can use KGS, I guess.

The simplest immediate solution would be for Dirceu to make a release
where he pins down the versions of the megrok.form dependencies in its
setup.py. I think he should do that. Then we all work with the same set
of versions, and we can find bugs like this sooner.

The problem with this approach is that you then don't have the choice to
upgrade an underlying library; you're stuck with exactly those versions.
I think we should live with that for the time being though...

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev at zope.org
http://mail.zope.org/mailman/listinfo/grok-dev