[Zope3-dev] Re: [SpringCleaning07]
Martijn Faassen
faassen at startifact.com
Tue Dec 19 10:01:25 EST 2006
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
More information about the Zope3-dev
mailing list