[Grok-dev] Grok-1.1a2 released!

[Jan-Wijbrand Kolman]

Reinout van Rees <reinout at vanrees.org> wrote: 
> On 12/22/09 11:43 PM, Jan-Wijbrand Kolman wrote:
>> The ZTK will not only make available newer features and bugfixes in
>> toolkit libraries, but also a less complex dependency structure of these
>> libraries encouraging more reuse.
> 
> .... but grok itself still places everything from the kitchen sink to 
> zope.app.i_dont_know_what in its install_requires.  There's a note in 
> there: "deprecated packages, there for backwards compatibility" after 
> which three zope.app packages are included.

You're right of course. We did not clean up as much as we could have in grok 
itself. The grokcore.* family however feels cleaner already.

> Presumably to make sure that people that do an 
> "install_requires=['grok']" get the list of packages they're used to.

That could be the reason, yes. But then we should these users to include 
these packages as dependencies in their setup.py files themselves. A 
documentation issue. We should amend the upgrade notes for this.

> The effect is that I added some 10 additional packages to that list.
> 
> Here's the current list (basically reported by z3c.dependencychecker):
> 
> # deprecated packages, there for backwards compatibility
> 'zope.app.error',
> 'zope.app.securitypolicy',
> 'zope.app.session',
> # Reported as unused by z3c.dependencychecker.  Should
> # be removed or moved to the deprecated packages list.
> 'zope.app.appsetup',
> 'zope.app.pagetemplate',
> 'zope.app.security',
> 'zope.app.twisted',
> 'zope.deprecation',
> 'zope.dottedname',
> 'zope.hookable',
> 'zope.i18nmessageid',
> 'zope.pagetemplate',
> 'zope.proxy',
> 'zope.viewlet',
> 
> 
> So: are those first three packages special?  Can they be removed?  What 
> about the rest?  Someone knowledgeable that wants to make the call?
> 
> "we're removing dependencies" is true for the grokcore.* packages, but 
> in this way, it is not true for grok itself :-)

I think we should "just" remove them, run the tests and the compattests and 
see what happens - not only for grok (and grokcore.*), but also in our own 
applications.

We could do that in the form of a quick next release.

regards,
jw