[Nitro] Facets 2.0 and the World of Bundles

[transfire at gmail.com]

Hi--

Time to reveal my surprise...

I have been working on a small project called GemBundles. Gembundles
are ordinary gems but they have an extra section for bundling
dependencies. This allows one to make multi-packages and avoid
downloading dependencies.

So what's this have to do with Nitro?

For Facets 2.0, I want to spin-off parts of the library into their own
packages. Now I haven't decided exactly how I want to do this. Either
the packages will be categorizations of Facets' libs --which will
still keep the whole rather tight knit, while allowing parts to still
be used independently if need be. Or the packages will be on their
own, with their own unique names and development tracks --in which
case Facets itself becomes just the core extensions and the most
general of the "more" components.

Now, if the former choice, little changes for Nitro, except that it
will probably want to ultimately depend on the "facetsbundle" package
in order to avoid directly handling a dozen or so dependencies at
installation time.

But if the later, well, things get interesting here. Nitro will want
to create it's own _special bundle_ containing the various libs it
requires. This will of course include Facet's core extensions and the
general components, and some of the independent spun-off packages.
But, unlike now, Nitro need not include any it doesn't use, AND Nitro
is at greater liberty to choose dependencies from outside sources
other than Facets. Going this route, Nitro could in fact name this
bundle "Glue". How's that for coming full circle?

At this point I have to makes a choice: Should Facets remain the super
uber-lib, containing nearly any common library under the sun, but
neatly categorized? Or should I refine Facets to it's most general
features and spin-off the more specialized parts? There are trade-offs
to each of course. On the one hand, we have a large comprehensive "one-
stop-shop" library, well organized, and with high name recognition. On
the other, we have a variety of libs from which to pick and choose,
each specialized to a particular need, with independent development
tracks and announcements. In essence it is a choice of greater
Uniformity vs greater Flexibility. It's a difficult choice, and I am
torn between them.

For Nitro that decision basically boils down to whether Nitro prefers
to depend on one comprehensive mega-library, or would it rather have
the added flexibility to bundle together a variety of smaller libs at
it's discretion?

T.