[Zope3-dev] More thoughts on packaging

[Phillip J. Eby]

At 01:30 PM 2/13/04 -0500, 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.

I haven't been following the packaging discussion that closely, so I may be 
projecting the following from a different set of requirements in mind than 
what you have.  So, apologies in advance if this is completely off-base 
from where you're heading...

Suppose that we put dependency metadata in package directories as an extra 
file, and then we wrote a 'package.py' script that generates a custom 
'setup.py' from the metadata, based on an intended target.  E.g. 
'package.py sometarget'.

Advantages:

* Leverages distutils packaging system support, since you can build Windows 
.exes, RPMs, source tarballs, etc.

* Takes advantage of any future distutils support for additional packaging 
systems

* Keeps the metadata lightweight and focused on Zope-specific needs

* Doesn't require anyone to learn another "full" packaging system


Disadvantages:

* Has to be written (but is relatively lightweight)


The metadata could actually be provided in the form of a Python module 
(e.g. '__setup__.py')  that defines any extensions, datafiles, etc., as 
well as "provides" and "requires" keys.

The 'package.py' script would write a 'setup.py' script that would look 
something like:

execfile('setupstuff/prologue.py')

gatherSetup('src/some/pkg1/__setup__.py')
gatherSetup('src/other/something/__setup__.py')

# ... etc, etc.

execfile('setupstuff/epilogue.py')

Based on sorting out the dependencies.  'epilogue' would then call the 
distutils 'setup' function with the accumulated data.


>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).
>
>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.
>
>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.