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:49:30 GMT
On Mon, Jan 5, 2009 at 3:30 PM, Daniel Spiewak <> wrote:
> Conceptually, shell:jirb *is* a compound task.  I read that as "in the shell
> namespace, execute the jirb task".  It isn't logically parametrized at all,
> it just happens to be dynamically created.  The clincher for me is the fact
> that the shell:* namespace is finite and well-defined, whereas test
> (which *should
> be* logically parametrized) has an unfixed domain.

Indeed there is a fundamental difference between "execute the
shell:jirb" task, and "execute the shell task using jirb".

In the first case, if you have shell:jirb and shell:irb, these are two
different tasks.  You can execute both.  Each one is configured
independently, has its own dependencies, etc.

In the second case, there's one shell task.  You tell it which runtime
to use.  It's like throwing a toggle switch, the same way I run specs
with Ruby and JRuby (have to test with both), I can run the same shell
task with either one.

I'm not convinced we need a lot of shell tasks. I can see the utility
in being able to flip that switch, maybe I like using irb and you like
using jirb, or I need to run with both for testing purposes. It's
easier to flip the switch from the command line than edit the
buildfile, so it's a nice feature to have.

I guess what it boils down to is, I see myself using shell a lot, I
don't see myself using a lot of shells.


> Daniel
> On Mon, Jan 5, 2009 at 5:18 PM, Assaf Arkin <> wrote:
>> 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
>> implementation.
>> 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
>> name.
>> 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.
>> Assaf
>> >
>> > alex
>> >

View raw message