[Grok-dev] Grok-1.1a2 released!
janwijbrand at gmail.com
Wed Dec 23 04:00:01 EST 2009
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
> # Reported as unused by z3c.dependencychecker. Should
> # be removed or moved to the deprecated packages list.
> 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
We could do that in the form of a quick next release.
More information about the Grok-dev