Stephan Richter wrote:
On Tuesday 19 December 2006 06:16, Roger Ineichen wrote:
Here is a list of candidates for removal (please verify!):
zope.dependencytool
-1, it is used by people to find dependencies in their packages. It is not
referenced anywhere in the code, because it is a standalone utility.
zope.importtool
-1, ditto to zope.dependencytool. Finding all the unused imports in a package
is very useful and people do this from time to time. Clearly this code is not
used anywhere, because it represents a standalone utility.
If these are standalone utilities, what about maintaining them outside
the core as standalone utilities, and not as part of Zope 3 at all?
[snip]
zope.app.file
-1, I use it all the time in combination with zope.app.image to have quick
file support. This is acceptable, if you do not plan to store thousands of
large documents. BTW, I would welcome a conversion to use blobs.
From the feedback from various points it looks clear that this one will
stay in for a while.
I would suggest the following packages in addition to the ones above:
- zope.app.i18nfile
This package was only a demo early on, but I think we can remove it now.
+1
- zope.app.homefolder
I know that some people -- particularly Florian Lindner -- are using this
package. I think it should be available in the repository, but the use case
of a homefolder is very CMS-specific and does not need to be in the base Zope
3.
+1 Removing this sounds fine with me too.
- zope.app.preview
I think the template in this package could be merged into another one.
Don't know what it's for, removing it is fine with me. :)
- zope.app.recorder
I really hope noone is using this old way of doing functional tests anymore.
Even if they do, the recorder is not required for running them.
+1 to removing.
- zope.app.schemacontent
I really love this package, because it really demonstrates some fascinating
aspects of the Zope 3 API. However, it should not be part of the base
distribution or be in the source tree. :-\
+1
- zope.app.servicenames
While the deprecation warning says Zope 3.5, I really doubt that anyone has
still code based on services working with Zope 3.3. That would be a miracle.
I suggest you can remove it now.
Okay, if that's a miracle I support removing this too. :)
- zope.app.sqlscript
This package has for me the same importance as zope.app.dtmlpage and
zope.app.zptpage. It contains some nice code that shows how to use RDB
connections correctly, but I doubt that anyone is seriously using them.
SQLObject and ZAlchemy are just better options. I would leave it in the
repository, but remove it from the core tree.
+1
- zope.app.zopetop
It's dead for a long time.
+1
- zope.app.versioncontrol
I think better approaches have been provided. As far as I can remember, ZC
came out with their own package that fixes several design flaws of this
package.
+1
- zope.app.undo
Is anyone using this? I am certainly not. I think it can be removed. Phllip,
you put a lot of work into it, what do you think? However, I think the code
has a place in the repository, though there it runs in danger of quickly
being outdated.
This isn't used from the ZMI?
- zope.app.renderer
You can safely remove it from the base tree. It was not such a big success as
I was hoping for. Other approaches are easier. Note that wiki and bugtracker
still use this code, so it should be still available for those packages.
+1
- zope.app.sqlexpr
A truly simple example of writing new TALES expressions, but nothing that
should be any longer in the base tree; however, I would really like to keep
it in the repository. This could move into the z3c namespace.
+1
- zope.app.demo
This is a really tricky one. The point of the package is to collect
demonstration code and the point of it living in zope.app is that it will
always work. But does it belong here? I do not know. What do others think?
I think demo code should move outside of the Zope 3 tree. It would be in
a different namespace perhaps, or in a special demo section of the Zope
3 project directory.
- zope.app.styleguide
This package contains Zope 3 coding style conventions, but I am not sure it is
used as the canonical source for the conventions. I think the Wiki is more
central. I know Roger put a lot of time into the package, so maybe we can put
the information not contained in the wiki there and then remove the package.
+1. Coding style conventions aren't packages anyway, right? I'm fine
with maintaining this stuff in SVN under the Zope 3 project though, just
not as a Python package.
I'll note that the removal of several of the zope.app.* packages means a
further distancing from TTW, offering the casual newscomer even less to look
at. I am okay with this direction, but others might object strongly. This
should really be brought up on zope3-users or other high-level mailing lists.
What the ZMI is for needs a rethink; as part of the Grok project we hope
to replace it with an admin UI, not a development UI.
I'm fine with removing distracting TTW objects that make you think you
can do TTW development with Zope 3 while you really can't anyway.
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
