[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