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

Chris McDonough chrism at plope.com
Tue Feb 17 09:40:19 EST 2004


On Tue, 2004-02-17 at 09:30, Martijn Faassen wrote:
> Chris McDonough wrote:

> I must've been very unclear about the idea that you're developing a 
> product yourself. Are we so focused on developing in the Zope 3 tree 
> that we lost the concept of actually developing packages outside it? My 
> point is that I don't want to have to create foo and foo_browser in my 
> CVS repository if I'm creating the package 'foo'. In this scenario I 
> have nothing to do with the Zope 3 core development.
> 
> It's not unnatural for me to want to run directly from my CVS checkout, 
> and it's not unnatural that I want to branch and tag *everything* in it, 
> including UI components, in one go. Or update it with a single cvs 
> update, not in two separate modules.

I don't think it matters whether we're talking about 3rd party packages
or core packages.  It's the same issue for all, AFAICT.

The browser and non-browser parts don't need to be separate modules
within your CVS repository.  Maybe you have a 'foo' CVS module that
contains a setup.py, a 'foo' Python package and a 'foo_browser' Python
package.  The setup.py script performs the necessary magic to put each
of the packages into a shared directory (and updates ZCML?  How the heck
is that going to work, btw? ;-).  The packages and the install script
can be versioned as one unit within CVS, but they become two packages
when installed.

As a convenience, developers might choose to flip the "symlink instead
of copy" flag on the setup script, which would symlink the source of
each package into the install directory instead of allowing distutils to
copy it.  That way you could retain the CVS bookkeeping info for each
package but work on it in the context of the install tree.

Make any sense?  The fact that we are constrained by the contents of CVS
representing the eventual install hiearchy is something that has
contributed to spaghetti dependencies within Zope 2, I'd hate to see the
same thing happen for Zope 3.

- C



- C





More information about the Zope3-dev mailing list