[Zope3-dev] Re: More thoughts on packaging

[Philipp von Weitershausen]

Jim Fulton wrote:
> 
> There seems to be a possible consensus emerging that we should
> use a packaging system.  I suggest that we should use an existing
> system (or systems) such as RPM or the debian system and
> provide the ability to generate course-grained distributions
> from these systems for those systems (e.g. windows) that either
> don't have package systems or don't have package systems that
> we support.
> 
> Suppose, for example, that we support RPMs and Debian packages.
> We should still generate Zope source releases that don't require
> any OS package support.  These source releases might be mostly a
> collection of source packages (or derivatives) with some glue
> code to get them built and installed. In particular, a source
> release might look little or nothing like a CVS checkout.
> Similarly, a binary release might be largely a collection of binary
> packages (or derivatives).

+1

> Packaging should be largely independent of the repository structure.
> In particular, whether a package is or isn't included in a distribution
> should not have much of an effect on it's place in the repository.
> Whether a package is included in this or that distribution, or even the
> degree to which a package is "optional" is likely to change over time.
> It would be insane, IMO, to move a package whenever it's status changes.

Yes, you're probably right. But if we keep a bunch of different packages 
in one place, we need to do something about configuration. Right now 
you'll have to edit src/zope/app/configure.zcml to add or remove a 
zope.app package from global configuration. zope.products packages are 
enabled or disabled in products.zcml which is custom to every instance...

Btw, I think it's still ok to have a special place of core packages. 
Their status is unlikely to ever change.

> I think a Python package's status and it's relationship to
> other packages, especially its dependencies, should be captured in
> meta data, not in it's Python package location.

Yes. I suggested earlier (can't remember where, when and to whom ;)) to 
use some sort of human- and machine-readable metadata description. I 
dislike the idea of using Python packages. I'd rather like to go with 
ini-style or ZConfig-style text files. That's actually what I always 
disliked about distutils, setup.py being a Python script.

Philipp