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

[Phillip J. Eby]

At 02:08 PM 2/17/04 -0500, Chris McDonough wrote:
>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* ;-).

Well, so far virtually all my Zope X3 contributions are to ZConfig, so I'm 
not sure whether that counts.

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.


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

Well, you won't lose me, but I'll most definitely be annoyed.  :)


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


>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.  I use Zope 2 ZPublisher without ZServer, 
and I can't see any possible reason ZPublisher should depend on 
ZServer.  None whatsoever.  Zip.  Nada.  As for the inverse, I don't know 
and don't care because I don't use ZServer.


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

IMO, your use case here can be solved by *repository* symlinks.  For 
example, PEAK's CVS area symlinks in the 'protocols' package directory of 
PyProtocols in order to bundle it in the PEAK "superpackage".