[Zope3-dev] directory hierarchy proposal

Casey Duncan casey@zope.com
Mon, 16 Dec 2002 00:13:17 -0500


On Sunday 15 December 2002 10:39 pm, Barry A. Warsaw wrote:
> >>>>> "JF" =3D=3D Jim Fulton <jim@zope.com> writes:
>=20
>     >> What about the convention that namespace package __init__.py
>     >> say something like this: # this is a namespace package, please
>     >> keep __init__.py empty of code This way anybody tempted to add
>     >> stuff to an __init__.py where they shouldn't will be made aware
>     >> immediately that they shouldn't do that.
>=20
>     JF> This is a good idea, It will need to be modified slightly,
>     JF> since it will contain some boilerplate code to knit all
>     JF> directories of the same name on the Python path into a single
>     JF> logical module.
>=20
> My biggest fear is that if there's anything more than a copyright
> comment in __init__.py, and different packages overwrite
> zope/__init__.py or zodb/__init__.py, we're going to get version skew
> pretty quickly.  That boilerplate is going to change and each
> individual package is going to have a slightly different version of
> the boilerplate.  I'd hate to have an up-to-date zodb package, then
> install SpoogyStorage with an older (or newer!) __init__.py that broke
> things.
>=20
> Maybe we can write some distutils code so that a new package will
> never overwrite namespace package's __init__.py file.

How about make? <duck>

Seriously though, if we explicitly comment __init__.py of all namespace=20
packages and put no code there, then I think we are ok. And why does=20
SpoogyStorage have to go in the ZODB package anyway? I would think it wou=
ld=20
be better as its own package if its an add-on.=20

I think the idea of one package overlaying the files of another when you=20
install it has worse implications than just overwriting __init__.py. If i=
t is=20
required for it to work I think this is a flaw in the design of the syste=
m=20
(or at least the base package) that should be corrected.

-Casey