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

[Philipp von Weitershausen]

Chris McDonough wrote:
> 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.

So, I'll to run something like 'make' after every friggin' change of a 
.py file? I think it's bad enough having to restart Z3 all the time. 
Hey, we're all using Python for it's being an interpreted language. 
Please let's not have compile-like processes.

I think we're making the CVS issue bigger than it is. Martijn, you're 
likely to have

silva
silva.publication
silva.publication_browser
...

So, you'll just do::

   martijn at infrae:~/silva$ cvs tag SILVA_3_0_0 publication*

I don't think it's that much harder.

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

A little. But I hate it :) Some kind of one-to-many-package mangling 
will confuse more than help and it's another point of possible failure, 
another thing to maintain etc. setup.py, as has been discussed lately, 
is hard to maintain, since it's monolithic, and don't even get me 
started on test.py! :)

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

I think we're currently solving this kind of problem with repo-links, 
e.g. with ZConfig and the like. Don't see why we wouldn't want to 
continue this.

Philipp