buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Interactive Shell Support
Date Mon, 05 Jan 2009 23:21:50 GMT
On Mon, Jan 5, 2009 at 3:14 PM, Daniel Spiewak <djspiewak@gmail.com> wrote:
> Implemented in GitHub fork, interactive-shell branch.
>
> Incidentally, I noticed that a lot of Buildr tasks have documentation right
> in the code.  Is this the correct way of doing things?  More specifically,
> Assaf wants the framework documented, so where should that go?

Usage instructions go in doc/pages, everything else (mostly API) in
the code itself.  So if someone wanted to start a shell from the
command line, they'd read about it in the guide.  If they wanted to
create a new shell, they'd lookup the API documentation for
Buildr::Shell (or whatever other module/class).

Assaf

>
> Daniel
>
> On Mon, Jan 5, 2009 at 5:00 PM, Alex Boisvert <boisvert@intalio.com> wrote:
>
>> On Mon, Jan 5, 2009 at 2:55 PM, Daniel Spiewak <djspiewak@gmail.com>
>> 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.
>>
>> alex
>>
>

Mime
View raw message