[Zope3-dev] Re: Packaging pre-proposal/notes

[Chris McDonough]

On Wed, 2004-02-18 at 11:25, Phillip J. Eby wrote:
> But I *don't* use Cygwin Python, even though I use the mingw32 tools to 
> compile.  So, symlinks still don't actually work for my setup.

Right.  Well, more Windows people around than I thought.  I really had
no idea, sorry!

> >Having a one-to-one relationship between a CVS checkout and a runnable
> >copy of Zope promotes the interdependency problem.  This is because
> >there is no way to capture the intent of dependencies within the tree
> >itself; newcomers to the software see the tree as one huge package.
> 
> Which is why we want per-package metadata.

Sometimes a "package" != a single Python package.  See ZODB, for
example.   I guess you could call this a "distribution", as it is made
up of several dependent Python packages.

This is handled now with repolinks, but this would seem to tie ZC to CVS
for the rest of time, or at least tie them to some version control
system that can also pretend to be a distribution system for the rest of
time.  Subversion doesn't seem to be able to do it, dunno about Arch or
Perforce or Bitkeeper or whatever.  Maybe relying on CVS for the
foreseeable future is ok.  Shrug.

But even if they seem to work ok, repolinks have their issues that make
them completely unacceptable for the purpose of ensuring that packages
don't have inappropriate dependencies.  As an example, ZODB doesn't even
try to live independently of Zope anymore.  Instead, ZODB releases are
now tied to Zope releases, so everything moves in lockstep.  It was just
too hard for people to manage the CVS merging that needed to happen in
order for ZODB to have a real life of its own.  Maybe this is a process
fault, but the technology sure didn't help either.

Shouldn't a Zope release (or any software release) be composed of
specific release versions of its constituent packages instead of some
huge master package perpetually asserting ownership over those packages
via a CVS tag that indicates *its* release, if the constituent packages
really are meant to be independently useful?

> >For example, in Zope 2, everyone knows that ZPublisher should probably
> >be able to depend on ZServer, but not vice versa.
> 
> Whaaaa???  IMO, absolutely not.

Ha.  I honestly have no real idea whether it should be able to or
shouldn't be able to!  Luckily, this actually proves the point I was
trying to make. ;)  There is no way to capture dependency intent without
grouping dependent packages into pure container "superpackages" or
having some sort of dependency system.  The dependency system is more
important than the superpackage use case, really, but I was trying to
service Martijn F's use case of wanting to version "foo" and
"browser_foo" together where each is a separate Python package with the
superpackage use case.

OK, I'm really out of time now, but since folks are dismissing the idea
out of hand, I did need to defend it. ;-)

- C