[Zope3-dev] Re: Where should we place 3rd party packages?

[Derrick 'dman' Hudson]

On Fri, Jul 02, 2004 at 05:28:49PM +0200, Roger ineichen wrote:
[...]

| Can we place a standard group container in the src/ for 3rd party
| packages like we did at the beginning with (zopeproducts) or
| lib/pyhton/Products in Zope2.
| 
| The reason why:
| If we write README's or some Installation instruction we don't have 
| a standard way of installing products. It whould be much more easiere
| for newbies ond also for to get a overview what's installed if
| we provide a standard way. 

Make a standard for your add-on only.  For example, I am (or plan to,
or whatever) create Zope3 software for 3 different groups.  I chose a
unique identifier for each group and make that the top-level package
for the software for that group (eg 'dman', 'iteams', and 'ros').
This similar to Java's package hierarchy where each organization has a
unique top-level package and they retain full control of the namespace
under that package.

| Or is there a reason for not doing this?

Zope2 demonstrates that the "one location" idea doesn't work so well
in practice.  For example (and this is not contrived!) the OS vendor
provides a zope package and packages for many add-ons.  You install
the vendor-supplied zope and some add-ons.  You want to install
additional add-ons that are not provided by the OS vendor.  The
problem is that the one directory for add-ons (eg
/usr/lib/zope/lib/python/Products) is in the filesystem area managed
by the package system and is only writeable by the system
administrator.  The OS vendor provides a per-instance Products
directory in a part of the filesystem allocated for site-local
management (the package system won't potentially clobber it).  This
directory (eg /var/lib/zope/instance/default/Products) is supposed to
be part of the python package 'Products'.  Python doesn't allow
package contents to be split across multiple locations, so zope must
do some dirty magic to make python's import think these two
directories are one and the same.  Additionally, this situation
creates potential confusion as to which 'Products' directory a given
product resides in.  Instead of following this same problematic path,
each organization or project should choose a unique top-level name for
their packages.

-D

PS. The notion of a single "zopeproducts" directory was discussed and
    rejected months ago.  The archives should contain the rationale
    behind the decision.

PPS. I'm not the one who made the decision, so don't complain to me.
     I simply read about it on the list.  :-)

-- 
"...In the UNIX world, people tend to interpret `non-technical user' as
meaning someone who's only ever written one device driver."
    --Daniel Pead
 
www: http://dman13.dyndns.org/~dman/            jabber: dman at dman13.dyndns.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040702/a8e88997/attachment.bin