[Pipet Devel] ideas for a smaller piper core

[J.W. Bizzaro]

Jarl van Katwijk wrote:
> 
> right. Maybe I'm missing the point here: are you looking for an easy way
> to install Piper? Practically bundling all needed components into on
> package is the most simple installation.

The point that I made in my first message was

  EASY = FEW EXTERNAL DEPENDENCIES 

True, making the external dependencies internal components will eliminate
them ;-)

I subsequently made the point

  EASY = MODULARITY

> > As you said, separate packaging will facilitate a quick change in
> > the standard, if needed.
> I'm not sure I got this one: are you saying separate packages allow a
> more flexible upgrade procedure?

That too.  I meant that when we want to change the "reference Piper", we
won't have to rip apart and reconfigure a directory tree and start
supporting serveral different trees.

> Also I'm not saying we should use separate packages for the distribution
> of Piper: use a complete tarball containing the best implementations  we
> got so for. Untill we got a nice installation procedure based on a fully
> documented Piper environment ;-)
> In short: supply as much functionality in one package untill we're no
> longer in alpha state. Something that could be very close to what you
> actaully want and did 1st post I guess. You seem to be lookin for the
> quickest way to get a simple working piece of code that's working?

In my first message, I was looking for the quickest way to get to beta, and
that could include folding dependencies into the source code.

Later on I was looking for the best solution for the long-run.  And I think
that would involve modularity to the extent that each component is developed
and distributed independently.

I would agree that we can keep one massive source tree until Piper is near
1.0, but I would like to split it up after that.

> This could be, and to my view should be, done in the configure script.
> Maybe have a try Jeff at chancing that script. It's very confusing
> systax at 1st, but you manage ;)

I'm much better with shell scripting than autoconf.  I'm tempted to write a
single install script for novices.

> There's is another PRO for an installation system that's capable of
> installing separate packages Jeff did not mention. An Piper that always
> installs the 4 default layers will overwrite or de-configure
> non-official parts during an upgrade.

Good point!

> So lets package 4 default layers into Piper, and make (some?) of them
> optional to install.

Would you agree that later on the components should be developed and
packaged separately?  I think we have 5 or 6 good reasons for doing so.

Cheers.
Jeff