[Zope3-dev] More thoughts on packaging

[Phillip J. Eby]

At 06:33 PM 2/13/04 -0500, Fred Drake wrote:
>On Friday 13 February 2004 05:49 pm, Phillip J. Eby wrote:
>  > The mental model I have in mind is that you have a "complete" source
>  > distribution from which you are "packaging" things.  So, let's say I
>  > wanted to make a "mini-Me" Zope distro that had only what was needed to
>  > support 'zope.publisher'.  I would check-out the entire Zope X3 source
>  > tree, and run something like 'package.py zope.publisher' (?) and then
>  > run setup.py to create source and binary distributions.
>
>That's one way to approach it.
>
>Another would be to feed the unsatisfied dependency information into
>distutils (somehow) so that when it generates an RPM, that RPM could have
>external dependencies based on the unsatisfied dependencies of the
>components you've told package.py to package.

What about Windows?  There's no packaging system there, certainly not one 
supported by distutils, AFAICT.  There's also that whole "somehow" part to 
deal with.  :)

Also, it negates the advantage of not having to learn another external 
packaging system, while seeming to add another N-way support issue.  So, I 
don't think I'd want it as the default usage of 'package.py'.  However, I 
do see the value in being able to provide it as an option that can be used 
if your packaging system of choice is supported, at some later date when 
the distutils has some kind of standard for "somehow".  :)


>It's only an issue of running untrusted code if the metadata is code.  I'd
>be glad to see it be entirely declarative if possible.  At that point, it
>doesn't need to be Python code, but can be some sort of configuration file,
>whether it be ZConfig (nice, but...) or ConfigParser (...available from the
>standard library, making a solution more acceptable for eventual inclusion
>in distutils itself) or even something else (truly sad if we can't reuse an
>existing tool).

Dunno, I've often found it quite handy to be able to use Python code in 
setups.  But I guess if I examine the use cases, most of them boil down to:

* Python version/platform checking (e.g. install the backported 'datetime' 
on 2.2, don't build FastCGI support on Win32, etc.)

* Scan directories to find files of particular types

* Enable/disable things according to options (this would be subsumed by 
package dependencies/inclusions)

* Build Pyrex extensions from either .c or .pyx depending on whether Pyrex 
is installed

But I imagine that there are probably ways to make a dumb configuration 
file support most of this.