[Nitro] Facets More & Glue

Michael Fellinger manveru at weez.co.jp
Fri Feb 10 12:38:55 EST 2006

Hey Trans,

Well, i'm not happy about the idea of having Glue (wich should be exactly what 
the name is - the glue between nitro/og/facets) being used for that.
It sounds more like an idea that will force us later to remove them again and 
to outsource what not really fits in there.

However, we all also followed the various attempts to get facets in a nice 
shape, with the main-problem being that nobody wants to have a big dependency 
but on the other side as much as possible around when it becomes neccesary, 
on the other hand you also never want to require something you don't need, 
just because it has something you need.
based on that many changes have been made so far - making everyone stumbling 
upon yet-another-concept of how facets works.
I don't say it was bad, but far from optimal - not blaming you, because you 
just tried to figure the best way out, despite of many attacks on ruby-lang.

Now, the best thing we can do is finding a final solution - basically 
splitting it into two projects doesn't seem like a bad idea... this is how i 
saw it from the very beginning and how i thought of it.
i am on the other hand not fond of having even more dependencies - how nice 
gems that might handle - at the moment we have:

nitro, og, glue, facets, facets_core, facets_more, gen, glue, breakpoint, 
daemons, (sqlite3, psql, mysql, kirbybase, mongrel, redcloth)

the last ones are of course optional, and i'm not sure about daemons anymore, 
they were neccesary a while ago.
Now, splitting facets into two projects would _decrease_ the number of 
dependencies by one! :)
So, the last thing is that they should have a twinny, rhyming name, 
facets_core facets_more doesn't sound bad - but the names don't say anything 
about what they contain...
Right now i cannot come up with something better, but i'm sure other people 
can do it.

Also i'm sorry about that lengthy post, i am a fan of summaries and just 
wanted to complete the picture a bit.


Am Saturday 11 February 2006 01:57 schrieb TRANS:
> Well, since George is around. I'm going to go ahead and put this out there.
> This whole ordeal with Facets Core/More/Nano/Mega/Carats/Calibre crap
> has just taken its toll on me. I have spent months trying to firgure
> out a resaonble solution. There doesn't seem to be one. The mess
> arises out of a complex mixture of circumstance, namely the
> fundamental distiction between the natures of the core and more parts,
> plus the way Ruby itself handles libraries, plus how setup.rb works to
> distribute them, and how RubyGems works to do the same. Taken all
> together it makes for a very ugly organization requiring extra special
> Rakefile tasks and/or Gemspecs to weave things together properly
> depending on the chosen dev layout. I have tried many posibilites over
> the last few months, and I think they all suck. I've even wrote a
> script that would change how Ruby requires libraries in light of it,
> but I realize that's an utterly worthless endevor*.
> So George wants to me to move Facets into the Nitro repository and
> make it an offical part of the Nitro project. I'm all for it. But I
> hesitate to do so until the problem is satisfactorily resolved.  But
> as I've said I no longer think there is a solution. That leaves only
> the possiblity that core and more should be two separate projects. I
> never wanted that, but I don't see any way around it. But I also don't
> wan't to to introduce another dependency into Nitro (not least of
> which reasons is b/c no name for said project has ever been
> satisfactory either). So right now I'm thinking the solution is to
> take the More part of Facets and merge it into Glue. Then Facets
> itself would just be the core extension methods. The only problem I
> have with that is that ideally these classes, modules and frameworks
> should be completely _generic_ (i.e usable without Nitro/Og), but some
> of the stuff in Glue currently only works in conjuction with Nitro/Og.
> Maybe that's not really a big deal, but it should at least be given
> consideration.
> T.
> *Politics within the Ruby community being what they are.
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

More information about the Nitro-general mailing list