[Zope3-dev] Re: More in zope.app: securitypolicy and wiki

[Jim Fulton]

Casey Duncan wrote:
> I get it now (thunk, thunk). I will attempt to summarize for my own
> edification:
> 
>  - A package's existence in the Zope3 repository has little or no
>    bearing on whether it is distributed with a Zope 3 distro.
> 
>  - Existence in the repository is designed to include it in
>    developer builds from checkouts so that code atrophy is less
>    likely.

Yay! You do get it. :)

> In theory this sounds pretty good. One concern I have is that it may
> lead to *everything* going into the repository which will be a
> bit of a burden on developers. Already a Zope3 checkout is a pretty
> weighty proposition. This will also create inertia since low level
> changes may break tests for "in repo" packages in ways the low
> level developer doesn't understand, especially in cases where tests
> make false assumptions about lower level services.  The upside is
> if course, the visibility of the breakage and the added urgency
> of failing tests in the zope package.

Exactly. At this point, we *want*:

- To get a greater sample of possible application breakage, by
   actually testing application ads well as "core" code.

- To make sure that existing sample applications keep running,
   even after restructuring.

Note that there is *still* a burden on checking things into
the Zope 3 tree:

- Must be comprehensive and *understandable* tests

- Must be a maintainer who can be consulted when there are
   questions.

- Must be at least somewhat useful.

Over time, we will remove some packages from the repository,
as we did recently with zope.context.

> I think we need a bit of package terminology to clarify things and
> replace the old "core", "non-core" terminology. Here are some
> suggestions:
> 
> "Zope Package" means any package under the "zope" package in cvs.
> "App Package" means any package under zope.app in cvs. Of course this
> means all app packages are zope packages.
> "Top-level packages" are the sibling packages to "zope"
> Packages outside of the Zope3 repository are called "outside packages".

OK

> Given this nascent terminology how does one determine whether something
> should be an app package, zope package, top-level package or outside 
> package?

In general, we will avoid non-zope packages. We will make some exceptions
to this, but these will be quite rare.  In general, software developed as
part of the Zope project will be either Zope packages or app packages.

A package should be a Zope package, not an App package if it is usable outside
of the Zope application server.  We encourage the creation of Zope packages.
We will often factor code into *both* a Zope package and an App package, to
allow as much usage outside of Zope, while providing necessary customization for the
app server.  Page-template support is a good example.


 > Sure, the latter could be a license/control descision. Aside
> from that given the disconnect between repository and distro (which is a
> great liberating thing IMO), what does the package structure in the repo
> actually mean?

What I said above. We will move to flat structures under zope, for things usable
outside of the app server, and inside app, for things that are designed for the
app server. Within Zope or App packages, we might have subpackages for different
presentation types or for tests. We will avoid any structure beyond this.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org