buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <>
Subject Re: Interactive Shell Support
Date Mon, 05 Jan 2009 23:18:41 GMT
On Mon, Jan 5, 2009 at 3:00 PM, Alex Boisvert <> wrote:
> On Mon, Jan 5, 2009 at 2:55 PM, Daniel Spiewak <> wrote:
>> Assaf's parametrized idea seems like the "proper" way to do this, but I
>> don't like the syntax.  At least to my eye, shell:jirb is *much* nicer and
>> more consistent with the "Buildr philosphy" than shell[jirb].  Besides, the
>> former is marginally easier to type.
> I feel the same way.   I'm curious to see if many Rake-based projects will
> adopt this new convention.
>> We could use your multiple-tasks idea without too much hardship in the
>> implementation.  I've got all the providers in a Hash, so a simple .each {
>> |lang, prov| define_task ... } should be sufficient.  I'm fine with doing
>> it
>> this way as long as y'all are ok with it.  :-)
> One precedent I can think of is the form "buildr test:SomeTest", which I
> like so I'm supportive of following our existing convention.

buildr test:<not task name> was written in the days of Rake 0.7.3,
it's a hack, painful to maintain and extend.  I've been longed
convinced its days are over, just didn't get around to do a better

Everywhere else, foo:bar means compound task name, it identifies the
task being executed.  Not so with test, where the last part is an
argument telling the test task what to do, but expressed as a task

Not only is an argument conceptually better, the code to implement and
test it is much simpler, and you can support multiple arguments.  Say
we wanted to give test two arguments, the class name and test name.

If you have shell.using(:jirb) in the project definition and
shell[jirb] on the command line, that looks consistent to me.  One is
setting default value, the other affecting it by argument.


> alex

View raw message