[zpkg] Packaging a standalone zope3 package
fred at zope.com
Mon Oct 24 14:11:04 EDT 2005
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
This forms part of the contract, as described above. As such, it is of
interest to designers/implementors (collectively: developers).
This contains information that is only needed by zpkg at the time a
distribution is constructed.
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.
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 L. Drake, Jr. <fred at zope.com>
More information about the zpkg