Hanno Schlichting wrote:

> - Look at Tres's list of packages in all three frameworks, decide on a way to
>   drop things from the initial ZTK set and on a process for the future.

As long as things are not dropped immediately. Even though Grok 1.2 
might not need foo.bar, transition support might mean it requires it 
still for those people who are porting over existing projects.

Note also that Tres' list is not exactly accurate as it comes to Grok, 
as Tres assumed that information about deprecation in Grok's setup.py 
was actually correct. :). Please be careful with that. I think Grok's 
upcoming 1.2 list will be better.

 > - Look at and update
 > http://docs.zope.org/zopetoolkit/about/coreextra.html for
 >   adding/removing policies, probably have a deprecated.cfg file

A deprecated.cfg would be a way to support this. Most of zopeapp.cfg 
could eventually go into deprecated.cfg.

The tricky question is what to do those things in zopeapp.cfg which 
won't be deprecated any time soon. An example is zope.app.wsgi. Should 
it stay in zopeapp.cfg? we could rename it to zope.wsgi and move it into 
the ztk.cfg too.

You can then argue that since Zope 2 doesn't use it, it shouldn't be in 
the ZTK, but there are already packages in the ZTK that aren't used by 
Zope 2. If we moved the four to six things out of zopeapp.cfg over into 
ztk.cfg (and deprecated the rest) might that be an acceptable extra 
burden for those who don't use these packages?

Eventually of course we'd even want to dump deprecated stuff completely 
so that we don't need to maintain it at all anymore. We can even move 
that code into a subdir in SVN and put markers in pypi. You'd need a 
clear procedure for that too.



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to