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

[Chris McDonough]

On Tue, 2004-02-17 at 12:19, Philipp von Weitershausen wrote:
> For example Windows people lose. Also, when you add new files, rename 
> them, refactor etc., you do not only have to make sure you get it right 
> in the revision control system, now you also have a symlink tree to take 
> care of...

Look, let's face it.  The number of Zope core developers that a) use
Windows, b) don't use Cygwin under Windows to develop Zope core and c)
own Visual C++ to be able to compile the requisite Zope C extensions is
pretty small, probably nearing 1 (*cough* Tim *cough* ;-).

Most Windows people install from binary, period.  And there's Cygwin,
which does symlinks just fine.  If people want to use Windows sans
Cygwin to develop Zope core, that's fine; they just need to copy the
files they change in the installed copy back into the source tree
manually and check them in.  The amount of people we would lose to such
a hardship is... zero.  Really.  The teeming throng of Windows people
here are free to stand up and prove me wrong. ;-)

Writing the additional logic into the package installer scripts (or
distutils) to do symlinks instead of copies for each subpackage of a
container directory full of packages is really not a big deal.  We're
not talking about needing to make a symlink for every new directory,
we're talking about needing to make a symlink for every new package. 
Developers will need to know when they add a package, because they'll
need to specify it in the distutils setup script anyway for installed
versions of Zope to run properly.

> > How is one setup script per package monolithic?
> 
> It's not. You must have misunderstood me. I too want a setup file for 
> each package. Though I dislike them being python scripts, but I could 
> even live with that. I guess they would just contain a lot of 
> boiler-plate, and I can only imagine them contaning descriptive 
> meta-data, not application logic.

OK, I think we completely agree about that.

> > Repolinks aside, the dogma of requring the CVS repository layout be the
> > same as the install layout prevents a lot of packaging flexibility;
> > namely, it prevents any possibility of having pure container directories
> > like I suggested in my last email.
> 
> I'm very close to calling YAGNI on this one. Maybe I just don't see it, 
> but what exact limitations are you talking about? What went wrong in 
> Zope2 because of it? I'm sure there are other ways for solving this...

There's just no way to use a *piece* of Zope 2, except possibly for
ZODB.  But that's only because ZODB has been explicitly maintained
separately, by separate people, as a separate package.  Other than ZODB,
Zope 2 really is a huge turd of interdependencies that cannot be
separated.

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.

For example, in Zope 2, everyone knows that ZPublisher should probably
be able to depend on ZServer, but not vice versa.  But where can I make
that assertion within a runnable checkout tree?  I can't.  In fact, this
is not the case.  In Zope 2, ZServer does now depend on ZPublisher. 
Why?  Because somebody didn't understand the intent of packaging them
separately.  Nobody has the time to play dependency police forever, so
these sorts of things slip in.  Over time, they come to bind the
software together in such a way that it cannot be separated.  This is
bad, because it reduces maintainability and chases Python folks away;
this "turdness" of Zope 2 is one of the main reasons that most Python
people are frightened of Zope: it's one huge module to them; they cannot
subdivide it into its component parts.

Now, distutils doesn't have the ability to spell dependencies right
now.  But at least it should be possible to group certain packages
together into "superpackages" which are maintained separately from one
other.  The proposed "foo" and "foo_browser" package set represents such
a superpackage.  Other superpackages may exist.  I'm just asserting that
the CVS tree be represented in terms of these superpackages rather than
in terms of how they should be laid out in an installed version.

FWIW, I'm out of time to promote my point of view about this, so I can't
respond to further talk about it, just wanted to say my peace. ;-)

- C