[Grok-dev] megrok.form errors

[Martijn Faassen]

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