[zpkg] Packaging a standalone zope3 package

[Fred Drake]

On Monday 24 October 2005 13:13, Lennart Regebro wrote:
 > No, but it clarifies a bit. It also simplifies, as you say, but only
 > to the point that the list of dependencies for zope is one instead of
 > three lines.

In this case, yes, the wildcard only saves a few lines.  In other cases, it 
can save more.  The savings of lines is a fairly minor point, I think, and is 
mostly interesting when additional packages are being added to a tree on an 
obgoing basis (as for the Zope 3 tree), because it avoids needing to update 
the map every time a package is added.

 > Actually, my main recommendation would be to get rid of all the
 > different config files, and put everything into one, with a
 > standardized name. That would make everything MUCH easier.

I've thought about that, and there's some serious appeal to that.  Jim has 
objected to the idea because he wants the dependencies information separate 
from the other packaging information because it's also part of the package's 
contract: it should be a considered design decision to change a released 
package to require packages it did not require before the change.

In principle, each of the files that can appear within a package has a 
different application:

DEPENDENCIES.cfg
  This forms part of the contract, as described above.  As such, it is of
  interest to designers/implementors (collectively: developers).

PACKAGE.cfg
  This contains information that is only needed by zpkg at the time a
  distribution is constructed.

PUBLICATION.cfg
  This contains information that distutils wants only for the "top-level"
  package in a distribution.  The "odd-ball" format is used since it exactly
  matches the format of the PKG-INFO files that distutils generates; we didn't
  have to invent something new, we simply expanded the application of the
  format (it's now input as well as output).  Given that ZC has gotten a lot
  of negative feedback for creating new formats in the past, we try to re-use
  existing formats when possible.

SETUP.cfg
  This contains information that, if present, distutils will need to when
  working with any package in a distribution, top-level or not.

That said, I completely agree that the importance of these distinctions isn't 
clear, and spreading information over several files isn't always a good idea.  
Having several packaging-related files in a Python package can be somewhat 
distracting, especially when dealing with small packages.


  -Fred

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