[Zope3-dev] Re: [SpringCleaning07]

[Martijn Faassen]

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