Interactive Shell Support

[Daniel Spiewak]

I use Buildr a lot for Scala, and one pattern I consistently repeat is
opening up an interactive shell based on the current classpath.
Unfortunately, this is a somewhat tedious operation given the fact that
Buildr manages the classpath in its entirety.  I imagine Groovy users run
into much the same issue on a fairly regular basis.  To solve this problem,
I have created a prototype implementation of Project.local_task('shell').
It can be invoked as follows:

# buildr shell

As long as you are within a project of a supported language, the relevant
interactive shell will be launched with the -classpath already set.  The
task itself is fairly generic, being just a front which selects a shell
provider based on language (like most of Buildr's framework).  If you aren't
using a supported language (i.e. Java), the task will fail with an
appropriate message.

The implementation is fairly rough.  The Scala shell works well, but there
is no support for JavaRebel as yet and the startup is sub-optimal (it
launches a separate process).  The Groovy shell support is just something I
hacked together.  It barely functions at all.  :-)

This is all available in my GitHub fork:
http://github.com/djspiewak/buildr/tree/master.  I would really love to see
this feature (or something like it) make it into the Buildr trunk/.  What
does everyone else think?

Daniel

P.S. Oh, the fork also contains a few other goodies I've been working on,
like a separate Specs provider and joint compilation for Scala and Java.
I'm not sure what the etiquette is on developing such features, so I just
threw them all into the master branch once I was done with their
development.  The tip of each feature is tagged for slightly-easier
cherry-picking, though there is some overlap in the DAG.

[Daniel Spiewak]

Correction.  I've done some playing with the repo and now the interactive
shell is separated into its own branch: interactive-shell.  This should make
it easier to evaluate in isolation from the separate-scala-specs and
scala-joint-compilation enhancements.  The master branch still contains all
three (since that's the one I'm using locally).

Daniel

On Sun, Jan 4, 2009 at 12:03 AM, Daniel Spiewak <djspiewak@...> wrote:

> I use Buildr a lot for Scala, and one pattern I consistently repeat is
> opening up an interactive shell based on the current classpath.
> Unfortunately, this is a somewhat tedious operation given the fact that
> Buildr manages the classpath in its entirety.  I imagine Groovy users run
> into much the same issue on a fairly regular basis.  To solve this problem,
> I have created a prototype implementation of Project.local_task('shell').
> It can be invoked as follows:
>
> # buildr shell
>
> As long as you are within a project of a supported language, the relevant
> interactive shell will be launched with the -classpath already set.  The
> task itself is fairly generic, being just a front which selects a shell
> provider based on language (like most of Buildr's framework).  If you aren't
> using a supported language (i.e. Java), the task will fail with an
> appropriate message.
>
> The implementation is fairly rough.  The Scala shell works well, but there
> is no support for JavaRebel as yet and the startup is sub-optimal (it
> launches a separate process).  The Groovy shell support is just something I
> hacked together.  It barely functions at all.  :-)
>
> This is all available in my GitHub fork:
> http://github.com/djspiewak/buildr/tree/master.  I would really love to
> see this feature (or something like it) make it into the Buildr trunk/.
> What does everyone else think?
>
> Daniel
>
> P.S. Oh, the fork also contains a few other goodies I've been working on,
> like a separate Specs provider and joint compilation for Scala and Java.
> I'm not sure what the etiquette is on developing such features, so I just
> threw them all into the master branch once I was done with their
> development.  The tip of each feature is tagged for slightly-easier
> cherry-picking, though there is some overlap in the DAG.
>

[Alex Boisvert-3]

I like the idea a lot.

Could this be a buildr plugin?

alex

On Sat, Jan 3, 2009 at 10:03 PM, Daniel Spiewak <djspiewak@...> wrote:

> I use Buildr a lot for Scala, and one pattern I consistently repeat is
> opening up an interactive shell based on the current classpath.
> Unfortunately, this is a somewhat tedious operation given the fact that
> Buildr manages the classpath in its entirety.  I imagine Groovy users run
> into much the same issue on a fairly regular basis.  To solve this problem,
> I have created a prototype implementation of Project.local_task('shell').
> It can be invoked as follows:
>
> # buildr shell
>
> As long as you are within a project of a supported language, the relevant
> interactive shell will be launched with the -classpath already set.  The
> task itself is fairly generic, being just a front which selects a shell
> provider based on language (like most of Buildr's framework).  If you
> aren't
> using a supported language (i.e. Java), the task will fail with an
> appropriate message.
>
> The implementation is fairly rough.  The Scala shell works well, but there
> is no support for JavaRebel as yet and the startup is sub-optimal (it
> launches a separate process).  The Groovy shell support is just something I
> hacked together.  It barely functions at all.  :-)
>
> This is all available in my GitHub fork:
> http://github.com/djspiewak/buildr/tree/master.  I would really love to
> see
> this feature (or something like it) make it into the Buildr trunk/.  What
> does everyone else think?
>
> Daniel
>
> P.S. Oh, the fork also contains a few other goodies I've been working on,
> like a separate Specs provider and joint compilation for Scala and Java.
> I'm not sure what the etiquette is on developing such features, so I just
> threw them all into the master branch once I was done with their
> development.  The tip of each feature is tagged for slightly-easier
> cherry-picking, though there is some overlap in the DAG.
>

[Daniel Spiewak]

Probably could be, but I'm not sure how well it would integrate then.  I
could certainly define a Project.local_task that way, but the problem is
that the language-specific providers wouldn't be as nicely separated or as
cleanly extensible.  The nice thing about having it in Buildr itself is it
provides a common framework.

Daniel

On Sun, Jan 4, 2009 at 11:06 AM, Alex Boisvert <boisvert@...> wrote:

> I like the idea a lot.
>
> Could this be a buildr plugin?
>
> alex
>
> On Sat, Jan 3, 2009 at 10:03 PM, Daniel Spiewak <djspiewak@...>
> wrote:
>
> > I use Buildr a lot for Scala, and one pattern I consistently repeat is
> > opening up an interactive shell based on the current classpath.
> > Unfortunately, this is a somewhat tedious operation given the fact that
> > Buildr manages the classpath in its entirety.  I imagine Groovy users run
> > into much the same issue on a fairly regular basis.  To solve this
> problem,
> > I have created a prototype implementation of Project.local_task('shell').
> > It can be invoked as follows:
> >
> > # buildr shell
> >
> > As long as you are within a project of a supported language, the relevant
> > interactive shell will be launched with the -classpath already set.  The
> > task itself is fairly generic, being just a front which selects a shell
> > provider based on language (like most of Buildr's framework).  If you
> > aren't
> > using a supported language (i.e. Java), the task will fail with an
> > appropriate message.
> >
> > The implementation is fairly rough.  The Scala shell works well, but
> there
> > is no support for JavaRebel as yet and the startup is sub-optimal (it
> > launches a separate process).  The Groovy shell support is just something
> I
> > hacked together.  It barely functions at all.  :-)
> >
> > This is all available in my GitHub fork:
> > http://github.com/djspiewak/buildr/tree/master.  I would really love to
> > see
> > this feature (or something like it) make it into the Buildr trunk/.  What
> > does everyone else think?
> >
> > Daniel
> >
> > P.S. Oh, the fork also contains a few other goodies I've been working on,
> > like a separate Specs provider and joint compilation for Scala and Java.
> > I'm not sure what the etiquette is on developing such features, so I just
> > threw them all into the master branch once I was done with their
> > development.  The tip of each feature is tagged for slightly-easier
> > cherry-picking, though there is some overlap in the DAG.
> >
>

[Assaf Arkin]

Why not start with a Scala shell?

Nothing against Groovy, but sounds like we have a couple of people  
ready to use the Scala shell. Get that done first, and well, then  
worry about other languages.

Assaf

On Jan 5, 2009, at 12:35 PM, "Daniel Spiewak" <djspiewak@...>  
wrote:

> Probably could be, but I'm not sure how well it would integrate  
> then.  I
> could certainly define a Project.local_task that way, but the  
> problem is
> that the language-specific providers wouldn't be as nicely separated  
> or as
> cleanly extensible.  The nice thing about having it in Buildr itself  
> is it
> provides a common framework.
>
> Daniel
>
> On Sun, Jan 4, 2009 at 11:06 AM, Alex Boisvert  
> <boisvert@...> wrote:
>
>> I like the idea a lot.
>>
>> Could this be a buildr plugin?
>>
>> alex
>>
>> On Sat, Jan 3, 2009 at 10:03 PM, Daniel Spiewak <djspiewak@...>
>> wrote:
>>
>>> I use Buildr a lot for Scala, and one pattern I consistently  
>>> repeat is
>>> opening up an interactive shell based on the current classpath.
>>> Unfortunately, this is a somewhat tedious operation given the fact  
>>> that
>>> Buildr manages the classpath in its entirety.  I imagine Groovy  
>>> users run
>>> into much the same issue on a fairly regular basis.  To solve this
>> problem,
>>> I have created a prototype implementation of  
>>> Project.local_task('shell').
>>> It can be invoked as follows:
>>>
>>> # buildr shell
>>>
>>> As long as you are within a project of a supported language, the  
>>> relevant
>>> interactive shell will be launched with the -classpath already  
>>> set.  The
>>> task itself is fairly generic, being just a front which selects a  
>>> shell
>>> provider based on language (like most of Buildr's framework).  If  
>>> you
>>> aren't
>>> using a supported language (i.e. Java), the task will fail with an
>>> appropriate message.
>>>
>>> The implementation is fairly rough.  The Scala shell works well, but
>> there
>>> is no support for JavaRebel as yet and the startup is sub-optimal  
>>> (it
>>> launches a separate process).  The Groovy shell support is just  
>>> something
>> I
>>> hacked together.  It barely functions at all.  :-)
>>>
>>> This is all available in my GitHub fork:
>>> http://github.com/djspiewak/buildr/tree/master.  I would really  
>>> love to
>>> see
>>> this feature (or something like it) make it into the Buildr  
>>> trunk/.  What
>>> does everyone else think?
>>>
>>> Daniel
>>>
>>> P.S. Oh, the fork also contains a few other goodies I've been  
>>> working on,
>>> like a separate Specs provider and joint compilation for Scala and  
>>> Java.
>>> I'm not sure what the etiquette is on developing such features, so  
>>> I just
>>> threw them all into the master branch once I was done with their
>>> development.  The tip of each feature is tagged for slightly-easier
>>> cherry-picking, though there is some overlap in the DAG.
>>>
>>

[Alex Boisvert-3]

I think the question is whether we want this in Buildr (I do) or it is
better to have a separate plugin.

Daniel seems to have prototypes for both Scala and Groovy already.

alex

On Mon, Jan 5, 2009 at 12:53 PM, Assaf Arkin <arkin@...> wrote:

> Why not start with a Scala shell?
>
> Nothing against Groovy, but sounds like we have a couple of people ready to
> use the Scala shell. Get that done first, and well, then worry about other
> languages.
>
> Assaf
>
>
> On Jan 5, 2009, at 12:35 PM, "Daniel Spiewak" <djspiewak@...> wrote:
>
>  Probably could be, but I'm not sure how well it would integrate then.  I
>> could certainly define a Project.local_task that way, but the problem is
>> that the language-specific providers wouldn't be as nicely separated or as
>> cleanly extensible.  The nice thing about having it in Buildr itself is it
>> provides a common framework.
>>
>> Daniel
>>
>> On Sun, Jan 4, 2009 at 11:06 AM, Alex Boisvert <boisvert@...>
>> wrote:
>>
>>  I like the idea a lot.
>>>
>>> Could this be a buildr plugin?
>>>
>>> alex
>>>
>>> On Sat, Jan 3, 2009 at 10:03 PM, Daniel Spiewak <djspiewak@...>
>>> wrote:
>>>
>>>  I use Buildr a lot for Scala, and one pattern I consistently repeat is
>>>> opening up an interactive shell based on the current classpath.
>>>> Unfortunately, this is a somewhat tedious operation given the fact that
>>>> Buildr manages the classpath in its entirety.  I imagine Groovy users
>>>> run
>>>> into much the same issue on a fairly regular basis.  To solve this
>>>>
>>> problem,
>>>
>>>> I have created a prototype implementation of
>>>> Project.local_task('shell').
>>>> It can be invoked as follows:
>>>>
>>>> # buildr shell
>>>>
>>>> As long as you are within a project of a supported language, the
>>>> relevant
>>>> interactive shell will be launched with the -classpath already set.  The
>>>> task itself is fairly generic, being just a front which selects a shell
>>>> provider based on language (like most of Buildr's framework).  If you
>>>> aren't
>>>> using a supported language (i.e. Java), the task will fail with an
>>>> appropriate message.
>>>>
>>>> The implementation is fairly rough.  The Scala shell works well, but
>>>>
>>> there
>>>
>>>> is no support for JavaRebel as yet and the startup is sub-optimal (it
>>>> launches a separate process).  The Groovy shell support is just
>>>> something
>>>>
>>> I
>>>
>>>> hacked together.  It barely functions at all.  :-)
>>>>
>>>> This is all available in my GitHub fork:
>>>> http://github.com/djspiewak/buildr/tree/master.  I would really love to
>>>> see
>>>> this feature (or something like it) make it into the Buildr trunk/.
>>>>  What
>>>> does everyone else think?
>>>>
>>>> Daniel
>>>>
>>>> P.S. Oh, the fork also contains a few other goodies I've been working
>>>> on,
>>>> like a separate Specs provider and joint compilation for Scala and Java.
>>>> I'm not sure what the etiquette is on developing such features, so I
>>>> just
>>>> threw them all into the master branch once I was done with their
>>>> development.  The tip of each feature is tagged for slightly-easier
>>>> cherry-picking, though there is some overlap in the DAG.
>>>>
>>>>
>>>

[Daniel Spiewak]

The Scala shell *is* basically done.  It's missing JavaRebel support, which
is kind-of a minor thing (incidentally, how should options like this be
passed to tasks?).  It also spawns a sub-process, rather than running in the
existing JVM.  I'm actually not sure that this is a bad idea, although it
does impose slightly more overhead.

If we want to focus on one language, then there's really no reason it
couldn't be as a plugin if it's better that way.  I just thought the idea of
a generic interactive shell framework was pretty cool.  If nothing else, it
makes for a nicely unified syntax for the functionality across the different
languages which Buildr supports.

Another thought: coming back to the generic framework, perhaps the shell
launched should be configurable?  It could default to whatever shell was
associated with the compile.language, but the user could also override in
the project definition to choose a different shell provider.  For example, I
use jirb a lot with Java projects (scala too come to think of it).

Daniel

On Mon, Jan 5, 2009 at 2:53 PM, Assaf Arkin <arkin@...> wrote:

> Why not start with a Scala shell?
>
> Nothing against Groovy, but sounds like we have a couple of people ready to
> use the Scala shell. Get that done first, and well, then worry about other
> languages.
>
> Assaf
>
>
> On Jan 5, 2009, at 12:35 PM, "Daniel Spiewak" <djspiewak@...> wrote:
>
>  Probably could be, but I'm not sure how well it would integrate then.  I
>> could certainly define a Project.local_task that way, but the problem is
>> that the language-specific providers wouldn't be as nicely separated or as
>> cleanly extensible.  The nice thing about having it in Buildr itself is it
>> provides a common framework.
>>
>> Daniel
>>
>> On Sun, Jan 4, 2009 at 11:06 AM, Alex Boisvert <boisvert@...>
>> wrote:
>>
>>  I like the idea a lot.
>>>
>>> Could this be a buildr plugin?
>>>
>>> alex
>>>
>>> On Sat, Jan 3, 2009 at 10:03 PM, Daniel Spiewak <djspiewak@...>
>>> wrote:
>>>
>>>  I use Buildr a lot for Scala, and one pattern I consistently repeat is
>>>> opening up an interactive shell based on the current classpath.
>>>> Unfortunately, this is a somewhat tedious operation given the fact that
>>>> Buildr manages the classpath in its entirety.  I imagine Groovy users
>>>> run
>>>> into much the same issue on a fairly regular basis.  To solve this
>>>>
>>> problem,
>>>
>>>> I have created a prototype implementation of
>>>> Project.local_task('shell').
>>>> It can be invoked as follows:
>>>>
>>>> # buildr shell
>>>>
>>>> As long as you are within a project of a supported language, the
>>>> relevant
>>>> interactive shell will be launched with the -classpath already set.  The
>>>> task itself is fairly generic, being just a front which selects a shell
>>>> provider based on language (like most of Buildr's framework).  If you
>>>> aren't
>>>> using a supported language (i.e. Java), the task will fail with an
>>>> appropriate message.
>>>>
>>>> The implementation is fairly rough.  The Scala shell works well, but
>>>>
>>> there
>>>
>>>> is no support for JavaRebel as yet and the startup is sub-optimal (it
>>>> launches a separate process).  The Groovy shell support is just
>>>> something
>>>>
>>> I
>>>
>>>> hacked together.  It barely functions at all.  :-)
>>>>
>>>> This is all available in my GitHub fork:
>>>> http://github.com/djspiewak/buildr/tree/master.  I would really love to
>>>> see
>>>> this feature (or something like it) make it into the Buildr trunk/.
>>>>  What
>>>> does everyone else think?
>>>>
>>>> Daniel
>>>>
>>>> P.S. Oh, the fork also contains a few other goodies I've been working
>>>> on,
>>>> like a separate Specs provider and joint compilation for Scala and Java.
>>>> I'm not sure what the etiquette is on developing such features, so I
>>>> just
>>>> threw them all into the master branch once I was done with their
>>>> development.  The tip of each feature is tagged for slightly-easier
>>>> cherry-picking, though there is some overlap in the DAG.
>>>>
>>>>
>>>

[Daniel Spiewak]

Oh, just to add, I'm willing to put in the effort to flesh out the
implementation some more.  I wouldn't mind polishing the Scala provider
completely and perhaps adding a provider for jirb, beefing up the framework
to allow user-specified shell, etc...  Just so you know that I'm not dumping
it all on you guys.  :-)

Daniel

On Mon, Jan 5, 2009 at 3:44 PM, Daniel Spiewak <djspiewak@...> wrote:

> The Scala shell *is* basically done.  It's missing JavaRebel support, which
> is kind-of a minor thing (incidentally, how should options like this be
> passed to tasks?).  It also spawns a sub-process, rather than running in the
> existing JVM.  I'm actually not sure that this is a bad idea, although it
> does impose slightly more overhead.
>
> If we want to focus on one language, then there's really no reason it
> couldn't be as a plugin if it's better that way.  I just thought the idea of
> a generic interactive shell framework was pretty cool.  If nothing else, it
> makes for a nicely unified syntax for the functionality across the different
> languages which Buildr supports.
>
> Another thought: coming back to the generic framework, perhaps the shell
> launched should be configurable?  It could default to whatever shell was
> associated with the compile.language, but the user could also override in
> the project definition to choose a different shell provider.  For example, I
> use jirb a lot with Java projects (scala too come to think of it).
>
> Daniel
>
>
> On Mon, Jan 5, 2009 at 2:53 PM, Assaf Arkin <arkin@...> wrote:
>
>> Why not start with a Scala shell?
>>
>> Nothing against Groovy, but sounds like we have a couple of people ready
>> to use the Scala shell. Get that done first, and well, then worry about
>> other languages.
>>
>> Assaf
>>
>>
>> On Jan 5, 2009, at 12:35 PM, "Daniel Spiewak" <djspiewak@...>
>> wrote:
>>
>>  Probably could be, but I'm not sure how well it would integrate then.  I
>>> could certainly define a Project.local_task that way, but the problem is
>>> that the language-specific providers wouldn't be as nicely separated or
>>> as
>>> cleanly extensible.  The nice thing about having it in Buildr itself is
>>> it
>>> provides a common framework.
>>>
>>> Daniel
>>>
>>> On Sun, Jan 4, 2009 at 11:06 AM, Alex Boisvert <boisvert@...>
>>> wrote:
>>>
>>>  I like the idea a lot.
>>>>
>>>> Could this be a buildr plugin?
>>>>
>>>> alex
>>>>
>>>> On Sat, Jan 3, 2009 at 10:03 PM, Daniel Spiewak <djspiewak@...>
>>>> wrote:
>>>>
>>>>  I use Buildr a lot for Scala, and one pattern I consistently repeat is
>>>>> opening up an interactive shell based on the current classpath.
>>>>> Unfortunately, this is a somewhat tedious operation given the fact that
>>>>> Buildr manages the classpath in its entirety.  I imagine Groovy users
>>>>> run
>>>>> into much the same issue on a fairly regular basis.  To solve this
>>>>>
>>>> problem,
>>>>
>>>>> I have created a prototype implementation of
>>>>> Project.local_task('shell').
>>>>> It can be invoked as follows:
>>>>>
>>>>> # buildr shell
>>>>>
>>>>> As long as you are within a project of a supported language, the
>>>>> relevant
>>>>> interactive shell will be launched with the -classpath already set.
>>>>>  The
>>>>> task itself is fairly generic, being just a front which selects a shell
>>>>> provider based on language (like most of Buildr's framework).  If you
>>>>> aren't
>>>>> using a supported language (i.e. Java), the task will fail with an
>>>>> appropriate message.
>>>>>
>>>>> The implementation is fairly rough.  The Scala shell works well, but
>>>>>
>>>> there
>>>>
>>>>> is no support for JavaRebel as yet and the startup is sub-optimal (it
>>>>> launches a separate process).  The Groovy shell support is just
>>>>> something
>>>>>
>>>> I
>>>>
>>>>> hacked together.  It barely functions at all.  :-)
>>>>>
>>>>> This is all available in my GitHub fork:
>>>>> http://github.com/djspiewak/buildr/tree/master.  I would really love
>>>>> to
>>>>> see
>>>>> this feature (or something like it) make it into the Buildr trunk/.
>>>>>  What
>>>>> does everyone else think?
>>>>>
>>>>> Daniel
>>>>>
>>>>> P.S. Oh, the fork also contains a few other goodies I've been working
>>>>> on,
>>>>> like a separate Specs provider and joint compilation for Scala and
>>>>> Java.
>>>>> I'm not sure what the etiquette is on developing such features, so I
>>>>> just
>>>>> threw them all into the master branch once I was done with their
>>>>> development.  The tip of each feature is tagged for slightly-easier
>>>>> cherry-picking, though there is some overlap in the DAG.
>>>>>
>>>>>
>>>>
>

[Alex Boisvert-3]

On Mon, Jan 5, 2009 at 1:44 PM, Daniel Spiewak <djspiewak@...> wrote:

> The Scala shell *is* basically done.  It's missing JavaRebel support, which
> is kind-of a minor thing (incidentally, how should options like this be
> passed to tasks?).


I think this is a good candidate for an environment variable.
(which can also be set via the buildr command-line)

 It also spawns a sub-process, rather than running in the
> existing JVM.  I'm actually not sure that this is a bad idea, although it
> does impose slightly more overhead.


I don't think this is a bad idea.   It might also be necessary for irb +
rjb.

Another thought: coming back to the generic framework, perhaps the shell
> launched should be configurable?  It could default to whatever shell was
> associated with the compile.language, but the user could also override in
> the project definition to choose a different shell provider.  For example,
> I
> use jirb a lot with Java projects (scala too come to think of it).


I would like that as well (smart default, project override) and even
command-line selection, e.g.

buildr myproject:shell:jirb

alex

[Daniel Spiewak]

I like the idea of an ENV and I *really* like the idea of invocation-point
selection (buildr myproject:shell:jirb).  How can this be done?  I know how
to declare a task relevant to a project, but how do I setup the :jirb
subtask?

Daniel

On Mon, Jan 5, 2009 at 4:00 PM, Alex Boisvert <boisvert@...> wrote:

> On Mon, Jan 5, 2009 at 1:44 PM, Daniel Spiewak <djspiewak@...>
> wrote:
>
> > The Scala shell *is* basically done.  It's missing JavaRebel support,
> which
> > is kind-of a minor thing (incidentally, how should options like this be
> > passed to tasks?).
>
>
> I think this is a good candidate for an environment variable.
> (which can also be set via the buildr command-line)
>
>  It also spawns a sub-process, rather than running in the
> > existing JVM.  I'm actually not sure that this is a bad idea, although it
> > does impose slightly more overhead.
>
>
> I don't think this is a bad idea.   It might also be necessary for irb +
> rjb.
>
> Another thought: coming back to the generic framework, perhaps the shell
> > launched should be configurable?  It could default to whatever shell was
> > associated with the compile.language, but the user could also override in
> > the project definition to choose a different shell provider.  For
> example,
> > I
> > use jirb a lot with Java projects (scala too come to think of it).
>
>
> I would like that as well (smart default, project override) and even
> command-line selection, e.g.
>
> buildr myproject:shell:jirb
>
> alex
>

[Assaf Arkin]

On Mon, Jan 5, 2009 at 1:45 PM, Daniel Spiewak <djspiewak@...> wrote:
> Oh, just to add, I'm willing to put in the effort to flesh out the
> implementation some more.  I wouldn't mind polishing the Scala provider
> completely and perhaps adding a provider for jirb, beefing up the framework
> to allow user-specified shell, etc...  Just so you know that I'm not dumping
> it all on you guys.  :-)

I think it's awesome and +1 adding it to Buildr core as a framework
that can support multiple languages/shells.

But not without documentation and specs.  We already have an issue
with undocumented/untested code that we're trying to offload (see
/addons).  A plugin is the easiest way I could think of to have other
people use it today, and get fixes/patched back into the code base.
Git branches are also good for that, but you can only use one branch
at a time, but multiple plugins.

Assaf

>
> Daniel
>
> On Mon, Jan 5, 2009 at 3:44 PM, Daniel Spiewak <djspiewak@...> wrote:
>
>> The Scala shell *is* basically done.  It's missing JavaRebel support, which
>> is kind-of a minor thing (incidentally, how should options like this be
>> passed to tasks?).  It also spawns a sub-process, rather than running in the
>> existing JVM.  I'm actually not sure that this is a bad idea, although it
>> does impose slightly more overhead.
>>
>> If we want to focus on one language, then there's really no reason it
>> couldn't be as a plugin if it's better that way.  I just thought the idea of
>> a generic interactive shell framework was pretty cool.  If nothing else, it
>> makes for a nicely unified syntax for the functionality across the different
>> languages which Buildr supports.
>>
>> Another thought: coming back to the generic framework, perhaps the shell
>> launched should be configurable?  It could default to whatever shell was
>> associated with the compile.language, but the user could also override in
>> the project definition to choose a different shell provider.  For example, I
>> use jirb a lot with Java projects (scala too come to think of it).
>>
>> Daniel
>>
>>
>> On Mon, Jan 5, 2009 at 2:53 PM, Assaf Arkin <arkin@...> wrote:
>>
>>> Why not start with a Scala shell?
>>>
>>> Nothing against Groovy, but sounds like we have a couple of people ready
>>> to use the Scala shell. Get that done first, and well, then worry about
>>> other languages.
>>>
>>> Assaf
>>>
>>>
>>> On Jan 5, 2009, at 12:35 PM, "Daniel Spiewak" <djspiewak@...>
>>> wrote:
>>>
>>>  Probably could be, but I'm not sure how well it would integrate then.  I
>>>> could certainly define a Project.local_task that way, but the problem is
>>>> that the language-specific providers wouldn't be as nicely separated or
>>>> as
>>>> cleanly extensible.  The nice thing about having it in Buildr itself is
>>>> it
>>>> provides a common framework.
>>>>
>>>> Daniel
>>>>
>>>> On Sun, Jan 4, 2009 at 11:06 AM, Alex Boisvert <boisvert@...>
>>>> wrote:
>>>>
>>>>  I like the idea a lot.
>>>>>
>>>>> Could this be a buildr plugin?
>>>>>
>>>>> alex
>>>>>
>>>>> On Sat, Jan 3, 2009 at 10:03 PM, Daniel Spiewak <djspiewak@...>
>>>>> wrote:
>>>>>
>>>>>  I use Buildr a lot for Scala, and one pattern I consistently repeat is
>>>>>> opening up an interactive shell based on the current classpath.
>>>>>> Unfortunately, this is a somewhat tedious operation given the fact that
>>>>>> Buildr manages the classpath in its entirety.  I imagine Groovy users
>>>>>> run
>>>>>> into much the same issue on a fairly regular basis.  To solve this
>>>>>>
>>>>> problem,
>>>>>
>>>>>> I have created a prototype implementation of
>>>>>> Project.local_task('shell').
>>>>>> It can be invoked as follows:
>>>>>>
>>>>>> # buildr shell
>>>>>>
>>>>>> As long as you are within a project of a supported language, the
>>>>>> relevant
>>>>>> interactive shell will be launched with the -classpath already set.
>>>>>>  The
>>>>>> task itself is fairly generic, being just a front which selects a shell
>>>>>> provider based on language (like most of Buildr's framework).  If you
>>>>>> aren't
>>>>>> using a supported language (i.e. Java), the task will fail with an
>>>>>> appropriate message.
>>>>>>
>>>>>> The implementation is fairly rough.  The Scala shell works well, but
>>>>>>
>>>>> there
>>>>>
>>>>>> is no support for JavaRebel as yet and the startup is sub-optimal (it
>>>>>> launches a separate process).  The Groovy shell support is just
>>>>>> something
>>>>>>
>>>>> I
>>>>>
>>>>>> hacked together.  It barely functions at all.  :-)
>>>>>>
>>>>>> This is all available in my GitHub fork:
>>>>>> http://github.com/djspiewak/buildr/tree/master.  I would really love
>>>>>> to
>>>>>> see
>>>>>> this feature (or something like it) make it into the Buildr trunk/.
>>>>>>  What
>>>>>> does everyone else think?
>>>>>>
>>>>>> Daniel
>>>>>>
>>>>>> P.S. Oh, the fork also contains a few other goodies I've been working
>>>>>> on,
>>>>>> like a separate Specs provider and joint compilation for Scala and
>>>>>> Java.
>>>>>> I'm not sure what the etiquette is on developing such features, so I
>>>>>> just
>>>>>> threw them all into the master branch once I was done with their
>>>>>> development.  The tip of each feature is tagged for slightly-easier
>>>>>> cherry-picking, though there is some overlap in the DAG.
>>>>>>
>>>>>>
>>>>>
>>
>

[Assaf Arkin]

On Mon, Jan 5, 2009 at 2:00 PM, Alex Boisvert <boisvert@...> wrote:

> On Mon, Jan 5, 2009 at 1:44 PM, Daniel Spiewak <djspiewak@...> wrote:
>
>> The Scala shell *is* basically done.  It's missing JavaRebel support, which
>> is kind-of a minor thing (incidentally, how should options like this be
>> passed to tasks?).
>
>
> I think this is a good candidate for an environment variable.
> (which can also be set via the buildr command-line)
>
>  It also spawns a sub-process, rather than running in the
>> existing JVM.  I'm actually not sure that this is a bad idea, although it
>> does impose slightly more overhead.
>
>
> I don't think this is a bad idea.   It might also be necessary for irb +
> rjb.
>
> Another thought: coming back to the generic framework, perhaps the shell
>> launched should be configurable?  It could default to whatever shell was
>> associated with the compile.language, but the user could also override in
>> the project definition to choose a different shell provider.  For example,
>> I
>> use jirb a lot with Java projects (scala too come to think of it).
>
>
> I would like that as well (smart default, project override) and even
> command-line selection, e.g.
>
> buildr myproject:shell:jirb

As of Rake 0.8, you can also do:

buildr myproject:shell[jirb]

You can have multiple arguments separated by commas.

Assaf

>
> alex
>

[Alex Boisvert-3]

On Mon, Jan 5, 2009 at 2:10 PM, Daniel Spiewak <djspiewak@...> wrote:

> I like the idea of an ENV and I *really* like the idea of invocation-point
> selection (buildr myproject:shell:jirb).  How can this be done?  I know how
> to declare a task relevant to a project, but how do I setup the :jirb
> subtask?


The following works but feels a little hackish...

module Shell
  include Extension

  first_time do
    desc 'start an interactive shell with compile+test classpath of project'
    Project.local_task('shell')
  end

  before_define do |project|
    # define a couple of tasks ...
    Rake::Task.define_task 'shell:jirb' do |name|
      puts "Running jirb for #{name}"
    end
    Rake::Task.define_task 'shell:scala' do |name|
      puts "Running scala for #{name}"
    end
  end

  after_define do |project|
    # figure out which shell should be default
    task 'shell' => 'shell:jirb'
  end
end

alex

[Daniel Spiewak]

Documentation is easy (I should be able to take care of that following the
model of the other frameworks).  As to specs, I can't even figure out how
Buildr's test setup works, so it's unlikely that I'll be able to help out
too much in that area.  :-)  If someone could point me to some documentation
on *this*, I would be much happier.

Daniel

On Mon, Jan 5, 2009 at 4:23 PM, Assaf Arkin <arkin@...> wrote:

> On Mon, Jan 5, 2009 at 1:45 PM, Daniel Spiewak <djspiewak@...>
> wrote:
> > Oh, just to add, I'm willing to put in the effort to flesh out the
> > implementation some more.  I wouldn't mind polishing the Scala provider
> > completely and perhaps adding a provider for jirb, beefing up the
> framework
> > to allow user-specified shell, etc...  Just so you know that I'm not
> dumping
> > it all on you guys.  :-)
>
> I think it's awesome and +1 adding it to Buildr core as a framework
> that can support multiple languages/shells.
>
> But not without documentation and specs.  We already have an issue
> with undocumented/untested code that we're trying to offload (see
> /addons).  A plugin is the easiest way I could think of to have other
> people use it today, and get fixes/patched back into the code base.
> Git branches are also good for that, but you can only use one branch
> at a time, but multiple plugins.
>
> Assaf
>
>
> >
> > Daniel
> >
> > On Mon, Jan 5, 2009 at 3:44 PM, Daniel Spiewak <djspiewak@...>
> wrote:
> >
> >> The Scala shell *is* basically done.  It's missing JavaRebel support,
> which
> >> is kind-of a minor thing (incidentally, how should options like this be
> >> passed to tasks?).  It also spawns a sub-process, rather than running in
> the
> >> existing JVM.  I'm actually not sure that this is a bad idea, although
> it
> >> does impose slightly more overhead.
> >>
> >> If we want to focus on one language, then there's really no reason it
> >> couldn't be as a plugin if it's better that way.  I just thought the
> idea of
> >> a generic interactive shell framework was pretty cool.  If nothing else,
> it
> >> makes for a nicely unified syntax for the functionality across the
> different
> >> languages which Buildr supports.
> >>
> >> Another thought: coming back to the generic framework, perhaps the shell
> >> launched should be configurable?  It could default to whatever shell was
> >> associated with the compile.language, but the user could also override
> in
> >> the project definition to choose a different shell provider.  For
> example, I
> >> use jirb a lot with Java projects (scala too come to think of it).
> >>
> >> Daniel
> >>
> >>
> >> On Mon, Jan 5, 2009 at 2:53 PM, Assaf Arkin <arkin@...> wrote:
> >>
> >>> Why not start with a Scala shell?
> >>>
> >>> Nothing against Groovy, but sounds like we have a couple of people
> ready
> >>> to use the Scala shell. Get that done first, and well, then worry about
> >>> other languages.
> >>>
> >>> Assaf
> >>>
> >>>
> >>> On Jan 5, 2009, at 12:35 PM, "Daniel Spiewak" <djspiewak@...>
> >>> wrote:
> >>>
> >>>  Probably could be, but I'm not sure how well it would integrate then.
>  I
> >>>> could certainly define a Project.local_task that way, but the problem
> is
> >>>> that the language-specific providers wouldn't be as nicely separated
> or
> >>>> as
> >>>> cleanly extensible.  The nice thing about having it in Buildr itself
> is
> >>>> it
> >>>> provides a common framework.
> >>>>
> >>>> Daniel
> >>>>
> >>>> On Sun, Jan 4, 2009 at 11:06 AM, Alex Boisvert <boisvert@...>
> >>>> wrote:
> >>>>
> >>>>  I like the idea a lot.
> >>>>>
> >>>>> Could this be a buildr plugin?
> >>>>>
> >>>>> alex
> >>>>>
> >>>>> On Sat, Jan 3, 2009 at 10:03 PM, Daniel Spiewak <djspiewak@...
> >
> >>>>> wrote:
> >>>>>
> >>>>>  I use Buildr a lot for Scala, and one pattern I consistently repeat
> is
> >>>>>> opening up an interactive shell based on the current classpath.
> >>>>>> Unfortunately, this is a somewhat tedious operation given the fact
> that
> >>>>>> Buildr manages the classpath in its entirety.  I imagine Groovy
> users
> >>>>>> run
> >>>>>> into much the same issue on a fairly regular basis.  To solve this
> >>>>>>
> >>>>> problem,
> >>>>>
> >>>>>> I have created a prototype implementation of
> >>>>>> Project.local_task('shell').
> >>>>>> It can be invoked as follows:
> >>>>>>
> >>>>>> # buildr shell
> >>>>>>
> >>>>>> As long as you are within a project of a supported language, the
> >>>>>> relevant
> >>>>>> interactive shell will be launched with the -classpath already set.
> >>>>>>  The
> >>>>>> task itself is fairly generic, being just a front which selects a
> shell
> >>>>>> provider based on language (like most of Buildr's framework).  If
> you
> >>>>>> aren't
> >>>>>> using a supported language (i.e. Java), the task will fail with an
> >>>>>> appropriate message.
> >>>>>>
> >>>>>> The implementation is fairly rough.  The Scala shell works well, but
> >>>>>>
> >>>>> there
> >>>>>
> >>>>>> is no support for JavaRebel as yet and the startup is sub-optimal
> (it
> >>>>>> launches a separate process).  The Groovy shell support is just
> >>>>>> something
> >>>>>>
> >>>>> I
> >>>>>
> >>>>>> hacked together.  It barely functions at all.  :-)
> >>>>>>
> >>>>>> This is all available in my GitHub fork:
> >>>>>> http://github.com/djspiewak/buildr/tree/master.  I would really
> love
> >>>>>> to
> >>>>>> see
> >>>>>> this feature (or something like it) make it into the Buildr trunk/.
> >>>>>>  What
> >>>>>> does everyone else think?
> >>>>>>
> >>>>>> Daniel
> >>>>>>
> >>>>>> P.S. Oh, the fork also contains a few other goodies I've been
> working
> >>>>>> on,
> >>>>>> like a separate Specs provider and joint compilation for Scala and
> >>>>>> Java.
> >>>>>> I'm not sure what the etiquette is on developing such features, so I
> >>>>>> just
> >>>>>> threw them all into the master branch once I was done with their
> >>>>>> development.  The tip of each feature is tagged for slightly-easier
> >>>>>> cherry-picking, though there is some overlap in the DAG.
> >>>>>>
> >>>>>>
> >>>>>
> >>
> >
>

[Daniel Spiewak]

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.

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.  :-)

Daniel

On Mon, Jan 5, 2009 at 4:45 PM, Alex Boisvert <boisvert@...> wrote:

> On Mon, Jan 5, 2009 at 2:10 PM, Daniel Spiewak <djspiewak@...>
> wrote:
>
> > I like the idea of an ENV and I *really* like the idea of
> invocation-point
> > selection (buildr myproject:shell:jirb).  How can this be done?  I know
> how
> > to declare a task relevant to a project, but how do I setup the :jirb
> > subtask?
>
>
> The following works but feels a little hackish...
>
> module Shell
>  include Extension
>
>  first_time do
>    desc 'start an interactive shell with compile+test classpath of project'
>    Project.local_task('shell')
>  end
>
>  before_define do |project|
>    # define a couple of tasks ...
>    Rake::Task.define_task 'shell:jirb' do |name|
>      puts "Running jirb for #{name}"
>    end
>    Rake::Task.define_task 'shell:scala' do |name|
>      puts "Running scala for #{name}"
>    end
>  end
>
>  after_define do |project|
>    # figure out which shell should be default
>    task 'shell' => 'shell:jirb'
>  end
> end
>
> alex
>

[Alex Boisvert-3]

On Mon, Jan 5, 2009 at 2:55 PM, Daniel Spiewak <djspiewak@...> 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

[Daniel Spiewak]

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?

Daniel

On Mon, Jan 5, 2009 at 5:00 PM, Alex Boisvert <boisvert@...> wrote:

> On Mon, Jan 5, 2009 at 2:55 PM, Daniel Spiewak <djspiewak@...>
> 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
>

[Assaf Arkin]

On Mon, Jan 5, 2009 at 3:00 PM, Alex Boisvert <boisvert@...> wrote:

> On Mon, Jan 5, 2009 at 2:55 PM, Daniel Spiewak <djspiewak@...> 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
>

[Assaf Arkin]

On Mon, Jan 5, 2009 at 3:14 PM, Daniel Spiewak <djspiewak@...> 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@...> wrote:
>
>> On Mon, Jan 5, 2009 at 2:55 PM, Daniel Spiewak <djspiewak@...>
>> 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
>>
>

[Daniel Spiewak]

Incidentally, should we make tasks like `shell:jirb` project-local, or just
`shell`?

Daniel

On Mon, Jan 5, 2009 at 5:00 PM, Alex Boisvert <boisvert@...> wrote:

> On Mon, Jan 5, 2009 at 2:55 PM, Daniel Spiewak <djspiewak@...>
> 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
>