[Zope3-dev] More thoughts on packaging

[Fred Drake]

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.

I'm not sure that either way is better, and I doubt we need to provide 
solutions for both approaches.  We just need to pick one.  Using a 
granualar approach (letting platform packaging systems deal with external 
dependencies) seems more appealing to me.  It would be nice to end up in a 
situation such that if someone wants to extend their Zope installation with 
an optional component, they can just download that one piece, and not a new 
Zope.

 > Of course, it *would* be pretty cool if it could download dependencies. 

Cool, yes.  I think this is out of scope.  Given some sort of processable 
metadata, we can create directories that make it easy to locate any 
additional components based on the ones we need.  This also isn't holding 
things up the way maintaining setup.py files currently is.

 > If package metadata files (and their dependencies) were
 > accessed/referenced by URLs, and there were standardized
 > formats/methods/locations for downloading...  Hm.  But then there are
 > issues with things like the running of untrusted code, etc. etc.  I

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

 > Anyway, this keeps the scope of the effort from exploding
 > into "rewrite distutils" territory.

Yeah, but that's what we need in too many ways.  ;-(


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation