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

[Chris McDonough]

> > The installer would symlink packages (directories), not individual
> > files.
> 
> OK, think of adding and removing directories.

FWIW, it's not often (at least as borne out in Zope 2) that directories
are added or removed.  It happens maybe every two weeks or every month
or so that someone adds a directory.  It happens *very* infrequently
that someone removes a directory.  Under either circumstance,
invariably, someone on the receiving end of that change forgets to add
-d or a -P to their "cvs up" command, and they get an error when they
try to run the software, they figure it out, update, and everything is
ok, and nobody gets hurt.  I don't understand how the impact of my
suggestion is very different (except maybe for symlink removal, which,
really, isn't that big of a deal, given that it's a fairly small number
of directories we're talking about, and a "find -exec rm" could do the
job).

FWIW, as another point, every Zope 2 installation out there that I've
ever put in to production effectively uses checkouts and symlinks in a
like way, mainly to manage shared products directories.  Additionally,
each development Zope 2 instance home I've got on my own computer has a
Products directory full of symlinks like this that point to other
products in another directory that I share between instance homes.  This
is solving a packaging problem for me.  If I could have Zope participate
in that system, I would.  E.g.: do I really need 17 copies of ZCatalog
on my hard disk, one for each software home checkout, even though it
might not have changed between checkouts?

I just wonder what makes "core Zope" all that special that it's exempt
from this kind of thing, especially if you want it to be divisible at
some level?

> > I don't know why, except for inertia.  This is a complete
> > non-requirement from my perspective, for any Python software. 
> 
> 
> That's fine.
> 
>  From my perspective it is a huge requirement.
> 
> Note that I must not be the only one.  Python itself
> can be run from a CVS checkout.

To me, typing "cvs up -dP; make inplace" is just as easy as typing "cvs
up -dP" itself.  It's just such a small price to pay in the big scheme
of things.  But I won't continue to belabor the issue by presenting
counterpoints if there can't be a discussion about it, as you've already
said "no".

>  > If Zope 3
> > is really at some level a collection of more-or-less independent Python
> > packages, it should be possible to treat it as such by rearranging the
> > packages in their respective source versions and letting an installer
> > take care of placing them in the right directories at install time.  CVS
> > should not be responsible for this.
> 
> I agree 100%.  But I still insist on the convenience of not having
> to run an installtion script, much less rerun one every time I
> do a cvs up.

As far as I can tell, those requirements are at odds with one another. 
But maybe something else will fall out.  Shrug.

> >>Don't worry.  One of the main points of the discussion is to
> >>avoid having the CVS repository constrained by distributions.  Distributions
> >>need not (and probably won't) look anything like the repository.
> > 
> > 
> > I suspect that's backwards.   If a CVS checkout must be runnable
> > in-place, there will be likely be little need or desire to package for
> > distribution differently than as one big checkout turd,
> 
> Yes there will be,  Distributions will often contain different things than
> what's in the repository. There will be experimental things in the repository
> that don't make it in to distributions. Similarly, people will create distributions
> that contain additional software that's not in the repository.

I see what you're saying, but I suspect all of the inclusion and
disinclusion of packages will end up itself managed via CVS (as it is in
Zope 2), which just isn't the right tool for that job.  As a result, in
a year from now, it's likely that nobody will remember what the intent
was.

- C