[Zope3-dev] Package organization quandry

[Jim Fulton]

"Barry A. Warsaw" wrote:
> 
...

> But, referring back to the spaghetti thread (!), if the PageTemplate
> package is to be usable outside of Zope, I really want to see that
> spelled:
> 
>     from PageTemplate.PageTemplateFile import PageTemplateFile
> 
> IOW, code that uses PageTemplate should not have to prepend it with a
> Zope package prefix. 

Why? Why is it important not to append the prefix? The Zope package in
Zope 3 is purely a container package to avoid namespace polution.
Having a package be a subpackage of Zope does not imply dependency on
the rest of Zope.

Zope 3 was criticized for creating a bunch of top-level module or package
names, such as ImageFile and DateTime, that conflicted with names from 
other projects.  Zope 3 has has a number of packages, including Security, 
ComponentArchitecture, and Configuration that would be useful outside the
Zope application server. These packages have names that could easily be
picked by other projects. Having them in the Zope package is for the purpose
of namespace control.

> You accomplish this by developing the
> PageTemplate package as a distutils package outside of any Zope
> context.  Then Zope's build procedure uses "setup.py install" with
> some magic options <wink> to install that in a directory that Zope
> guarantees is on sys.path before site-packages, e.g. lib/python in
> Zopespeak.

You are not suggesting a solution to the problem that the package
organization was designed to solve. The problem is a namespace problem, 
*not* an installation or repository problem.  I'm in favor of giving the
reusaable packages their own setup.py, but their setup should *still*
install them into the Zope package to avoid namespace conflicts.
 
> Note that this approach means that "Zope" (whatever that ends up
> meaning, probably the sumo tarball distribution) has its own blessed
> copies of independent packages, never installs them in site-packages,
> and actually never cares if someone else on the machine /has/
> installed them independently in site-packages because Zope's never
> gonna look there.

Right. I'm find with that. OTOH, it does have to worry whether software
that someone might want to use in Zope has the same names as Zope-provided
packages. It addresses this risk by providing it's own package namespace.
 
Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org