On Mon, Oct 15, 2012 at 10:46 AM, steve donovan
<steve.j.dono...@gmail.com> wrote:
> Hi all,
>
> Some time back I put pl.stringio up as a separate rock, since it's
> rather useful and it's a drag to have a whole big-ish library as a
> dependency.
>
> This argument applies to a number of the Penlight modules, of course.
> For instance, pl.template is basically Rici Lake's
> SlightlyLessSimplePreprocessor with customizable line and escape
> symbols.  So that's a candidate, call it 'riciprepro'.
>
> pl.config is a very flexible configuration file reader which
> understands both ini- and Unix-style formats, and I'm thinking of
> making it available as 'configfile'.
>
> There's a number of other modules that are candidates for this
> rockification, and I was wondering what people think generally of the
> utility and wisdom of this approach?
>
> (Before I start spamming the list with modules that aren't really that
> useful on their own!)

Usually, if you ask people "would you like to have this other option
as well?", people will answer yes -- "yeah, sure, another option, why
not. I may find a use for it at some point." Especially since it's no
extra work for them. :)

But is Penlight really _that_ big? I mean, if the goal was to have a
featureful general-purpose library, eventually winning some mindshare
as a provider of the "missing batteries", then I think those "top
seller" modules are what would push for its popularization, and then
people would be more likely to use the others after they're already
installed.

Isn't it paradoxical, if you came up with Penlight to tackle the
problem of fragmentation and provide a one-stop-shop for utilities, to
start fragmenting it?

If you're decided on breaking it in pieces, at the very least I'd call
them "penlight-config", "penlight-template", etc. Once they're all
broken up, however, should there still be a single "penlight" module
with duplicated content? Or will it become eventually a dummy rockspec
with only a list of dependencies?...

-- Hisham

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers

Reply via email to