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 Tue, 06 Jan 2009 00:15:07 GMT
On Mon, Jan 5, 2009 at 4:02 PM, Daniel Spiewak <djspiewak@gmail.com> wrote:
>> I think for most builds you only need one shell, so a per-buildfile
>> shell is easier to work with, configure, etc.
>
>
> The whole point to the shell framework is to launch a shell easily with the
> CLASSPATH already configured.  If we don't do that on a per-project basis,
> it's useless.

Say I'm working on a Web application, there's a lot of
components/modules involved, but I only really need to shell into one
place.  It's a shell that puts me in much the same place I'd be as the
server or a client (e.g I can use data access objects, or make
requests).  Most often than not, and I am thinking of very complicated
applications, I don't need more than one shell.

I do expect the shell to have the CLASSPATH already configured. And I
expect to do minimal work in the buildfile to get that CLASSPATH
configured. And I would expect, whichever directory I'm in, that
buildr shell drops me in the right shell with that one CLASSPATH.

Assaf

>> I know scenarios where I would like to (or have and so use) multiple
>> shells, but those are task-based not project-based. For example, when
>> working with Rails, I use the server console, database console
>> (embedded sqlite), and bash/irb for the client.
>>
>> So it would be nice if I could easy define new shells from the buildfile,
>> say:
>>
>> ShellTask.define_task('client').with( lots of dependencies )
>
>
> That would be pretty cool, though I'm not quite sure how it would work.
> This might also be useful if you want to start a shell which always
> pre-inits itself with some code (a bunch of imports for example, or a long
> setup task).
>
> Daniel
>

Mime
View raw message