Interactive Shell Support

[Daniel Spiewak]

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.

Daniel

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

> 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:30 PM, Daniel Spiewak <djspiewak@...> 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.

Assaf

>
> Daniel
>
> On Mon, Jan 5, 2009 at 5:18 PM, Assaf Arkin <arkin@...> wrote:
>
>> 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:28 PM, Daniel Spiewak <djspiewak@...> wrote:
> Incidentally, should we make tasks like `shell:jirb` project-local, or just
> `shell`?

I think for most builds you only need one shell, so a per-buildfile
shell is easier to work with, configure, etc.

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 )

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]

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

This is the situation I envision.  I like to test out stuff as I develop (in
Java) using an interactive shell.  Most of the time I want to use Scala's
shell for that.   However, there are a lot of times when a dynamic type
system is helpful.  In those cases, I prefer to use jirb since I like the
syntax better than groovysh.  However, when developing in Scala, I will
almost *always* use scala's shell.  Likewise, when developing in Groovy, I
will almost always use groovy's shell.

I see the "lots of shells" as more useful under Java development, which
doesn't have a de facto standard shell.

I do see your point though that most users will probably stick with just one
(usually the language default).

Daniel

[Daniel Spiewak]

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


> 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

[Assaf Arkin]

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

[Daniel Spiewak]

Ah, we have very different needs for this feature!  :-)  To me, the sort of
shell you describe would be nearly useless on complex projects.  I would
definitely want to get a different CLASSPATH if I'm in a sub-project.  The
main reason I want the shell is to test perform Lisp-style dynamic
development on internal classes which I'm still working on.  The external
interface to the project might be nice to hit, but that's a separate issue
for me.  Most of the time, my client-facing testing would be in the form of
unit tests requiring more setup than a shell can nicely accommodate.

Daniel

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

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

[Assaf Arkin]

On Mon, Jan 5, 2009 at 4:19 PM, Daniel Spiewak <djspiewak@...> wrote:
> Ah, we have very different needs for this feature!  :-)  To me, the sort of
> shell you describe would be nearly useless on complex projects.  I would
> definitely want to get a different CLASSPATH if I'm in a sub-project.  The
> main reason I want the shell is to test perform Lisp-style dynamic
> development on internal classes which I'm still working on.  The external
> interface to the project might be nice to hit, but that's a separate issue
> for me.  Most of the time, my client-facing testing would be in the form of
> unit tests requiring more setup than a shell can nicely accommodate.

I think the only difference is that I would have one CLASSPATH that
grows (and sometimes shrinks) over time, rather than jumping between
projects. A matter of style. I obviously prefer my style, but my
advise right now would be to pick one option, code it, and start using
it, and see over time if it feels restricting/annoying.

Also, open a JIRA issue for this enhancement so we can track it.

Assaf

>
> Daniel
>
> On Mon, Jan 5, 2009 at 6:15 PM, Assaf Arkin <arkin@...> wrote:
>
>> On Mon, Jan 5, 2009 at 4:02 PM, Daniel Spiewak <djspiewak@...>
>> 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
>> >
>>
>

[Daniel Spiewak]

> I think the only difference is that I would have one CLASSPATH that
> grows (and sometimes shrinks) over time, rather than jumping between
> projects. A matter of style. I obviously prefer my style, but my
> advise right now would be to pick one option, code it, and start using
> it, and see over time if it feels restricting/annoying.


Coded!  :-)  http://github.com/djspiewak/buildr  Branch: interactive-shell

It's worth noting that I rarely use sub-projects, so in practice my style
and yours are likely indistinguishable.  I'm curious as to the opinion of
the community at large.

Out of curiousity, in your style, you do you envision the shell task
determining the correct compile task?  This task must be a pre-requisite for
`shell`.  Also, the task needs to be able to locate CLASSPATH information
from somewhere.  If the task isn't project-local, where does it come from?

Also, open a JIRA issue for this enhancement so we can track it.


https://issues.apache.org/jira/browse/BUILDR-234

Daniel

[Assaf Arkin]

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

>> I think the only difference is that I would have one CLASSPATH that
>> grows (and sometimes shrinks) over time, rather than jumping between
>> projects. A matter of style. I obviously prefer my style, but my
>> advise right now would be to pick one option, code it, and start using
>> it, and see over time if it feels restricting/annoying.
>
>
> Coded!  :-)  http://github.com/djspiewak/buildr  Branch: interactive-shell
>
> It's worth noting that I rarely use sub-projects, so in practice my style
> and yours are likely indistinguishable.  I'm curious as to the opinion of
> the community at large.
>
> Out of curiousity, in your style, you do you envision the shell task
> determining the correct compile task?  This task must be a pre-requisite for
> `shell`.  Also, the task needs to be able to locate CLASSPATH information
> from somewhere.  If the task isn't project-local, where does it come from?

I was thinking something like (outside of any project definition):

shell.with project(...)

which will use compile target and dependencies and infer the target.

Assaf

>
> Also, open a JIRA issue for this enhancement so we can track it.
>
>
> https://issues.apache.org/jira/browse/BUILDR-234
>
> Daniel
>

[Daniel Spiewak]

> I was thinking something like (outside of any project definition):
>
> shell.with project(...)
>
> which will use compile target and dependencies and infer the target.


Hmm, I suppose that would work.  It does require some extra effort though,
whereas if we let the task be project local, everything can be inferred
automatically.

Daniel

[Daniel Spiewak]

One disadvantage I have found to the project local technique is the fact
that I can't figure out how to make tasks like 'shell:jirb' project local.
This means that if you want to launch a custom shell, you have to
fully-qualify the task:

buildr collection:shell:jirb

In other news, I have now added this mythical JIRB shell provider, as well
as a provider for the Clojure shell (id :clj).  Both of these depend on
their respective *_HOME environment variables.  The Groovy shell provider is
also now up to snuff, though I can't tell if the annoying associated app
launch is on purpose or not.

For everything except the Scala shell provider, we probably should
dynamically install the artifacts into the local repo, mirroring the compile
tasks.  I'm lazy though, and for the moment I've left this alone.  The one
exception is the JLine dependency for the Clojure shell, which I grab using
Buildr.artifact.

Incidentally, the Clojure shell might be something worth dropping just for
continuity, since nothing else in Buildr actually supports that language.
However, I figured there was no harm in implementing a quick prototype so we
can see how things will work.  This is all still in flux anyway.

Daniel

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

>
> I think the only difference is that I would have one CLASSPATH that
>> grows (and sometimes shrinks) over time, rather than jumping between
>> projects. A matter of style. I obviously prefer my style, but my
>> advise right now would be to pick one option, code it, and start using
>> it, and see over time if it feels restricting/annoying.
>
>
> Coded!  :-)  http://github.com/djspiewak/buildr  Branch: interactive-shell
>
> It's worth noting that I rarely use sub-projects, so in practice my style
> and yours are likely indistinguishable.  I'm curious as to the opinion of
> the community at large.
>
> Out of curiousity, in your style, you do you envision the shell task
> determining the correct compile task?  This task must be a pre-requisite for
> `shell`.  Also, the task needs to be able to locate CLASSPATH information
> from somewhere.  If the task isn't project-local, where does it come from?
>
> Also, open a JIRA issue for this enhancement so we can track it.
>
>
> https://issues.apache.org/jira/browse/BUILDR-234
>
> Daniel
>

[Assaf Arkin]

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

>> I was thinking something like (outside of any project definition):
>>
>> shell.with project(...)
>>
>> which will use compile target and dependencies and infer the target.
>
>
> Hmm, I suppose that would work.  It does require some extra effort though,
> whereas if we let the task be project local, everything can be inferred
> automatically.

Yes, but I only have to do it once when I write the buildfile. All the
times I run the shell, I don't have to cd into a specific directory,
or remember the qualified task name. So if you don't need different
shells for different projects (in the same build), overall there's
much less effort setting it up this way.

Assaf

>
> Daniel
>

[Daniel Spiewak]

> Yes, but I only have to do it once when I write the buildfile. All the
> times I run the shell, I don't have to cd into a specific directory,
> or remember the qualified task name. So if you don't need different
> shells for different projects (in the same build), overall there's
> much less effort setting it up this way.


Correction: if you *need* to *not* have different shells for different
projects, then you have to cd around or use the fully-qualified name.  If
you don't particularly care one way or another, the auto-magical config
option will be easier.  Critically, if you really do need separate shells,
then the project-local task is essential.  You can use your style with the
project-local implementation by simply typing the fully-qualified name (e.g.
buildr collection:shell OR buildr collection:shell:jirb).  However, if we go
with the One Shell to Rule Them All, then we're stuck with it; there's no
way to get a separate shell in a sub-project.

So in a sense, my scheme can be used to emulate yours, but the reverse is
not true.  It may take more syntax to use the shell in the manner you
describe, but at least it's possible.

Anyway, I'm curious as to the community's opinion here.  What is the
"accepted" technique for interactive shell usage?

Oh, on a syntactic note, Lispers would know the "shell" much better as a
REPL.  What's the preferred terminology?  I like shell because it's short
and relatively easy to understand, but maybe I'm the minority.  If someone
is expecting the interactive language shell to be called a "REPL", then they
would probably expect `buildr shell` to be some sort of interactive command
interface to Buildr itself (allowing you to run tasks).  Does this seem like
a potential problem or should we not fret over it?

Daniel

[Alex Boisvert-3]

On Tue, Jan 6, 2009 at 10:50 AM, Daniel Spiewak <djspiewak@...> wrote:

> > Yes, but I only have to do it once when I write the buildfile. All the
> > times I run the shell, I don't have to cd into a specific directory,
> > or remember the qualified task name. So if you don't need different
> > shells for different projects (in the same build), overall there's
> > much less effort setting it up this way.
>

The same could be said for the other approach.  You could easily have,

task 'shell' => 'myproject:shell:jirb'

in your project and be done with it.


> Oh, on a syntactic note, Lispers would know the "shell" much better as a
> REPL.  What's the preferred terminology?  I like shell because it's short
> and relatively easy to understand, but maybe I'm the minority.  If someone
> is expecting the interactive language shell to be called a "REPL", then
> they
> would probably expect `buildr shell` to be some sort of interactive command
> interface to Buildr itself (allowing you to run tasks).  Does this seem
> like
> a potential problem or should we not fret over it?


I think "shell" is the more common and broader name.   And as shown above,
it's easy to create an alias if you insist on a specific name.

alex

[Daniel Spiewak]

Oh I see, allow the task to be project local, just don't define the
local_task alias.  That would work, but again it's not as magical.

Daniel

On Tue, Jan 6, 2009 at 1:07 PM, Alex Boisvert <boisvert@...> wrote:

> On Tue, Jan 6, 2009 at 10:50 AM, Daniel Spiewak <djspiewak@...>
> wrote:
>
> > > Yes, but I only have to do it once when I write the buildfile. All the
> > > times I run the shell, I don't have to cd into a specific directory,
> > > or remember the qualified task name. So if you don't need different
> > > shells for different projects (in the same build), overall there's
> > > much less effort setting it up this way.
> >
>
> The same could be said for the other approach.  You could easily have,
>
> task 'shell' => 'myproject:shell:jirb'
>
> in your project and be done with it.
>
>
> > Oh, on a syntactic note, Lispers would know the "shell" much better as a
> > REPL.  What's the preferred terminology?  I like shell because it's short
> > and relatively easy to understand, but maybe I'm the minority.  If
> someone
> > is expecting the interactive language shell to be called a "REPL", then
> > they
> > would probably expect `buildr shell` to be some sort of interactive
> command
> > interface to Buildr itself (allowing you to run tasks).  Does this seem
> > like
> > a potential problem or should we not fret over it?
>
>
> I think "shell" is the more common and broader name.   And as shown above,
> it's easy to create an alias if you insist on a specific name.
>
> alex
>

[Alex Boisvert-3]

Sorry, I wasn't clear.

In my example, I was defining a top-level task "shell" that would be linked
to a project's specific shell task.

That way, you could do "buildr shell" instead of "buildr myproject:shell" or
"buildr myproject:shell:jirb"

alex


On Tue, Jan 6, 2009 at 11:34 AM, Daniel Spiewak <djspiewak@...> wrote:

> Oh I see, allow the task to be project local, just don't define the
> local_task alias.  That would work, but again it's not as magical.
>
> Daniel
>
> On Tue, Jan 6, 2009 at 1:07 PM, Alex Boisvert <boisvert@...>
> wrote:
>
> > On Tue, Jan 6, 2009 at 10:50 AM, Daniel Spiewak <djspiewak@...>
> > wrote:
> >
> > > > Yes, but I only have to do it once when I write the buildfile. All
> the
> > > > times I run the shell, I don't have to cd into a specific directory,
> > > > or remember the qualified task name. So if you don't need different
> > > > shells for different projects (in the same build), overall there's
> > > > much less effort setting it up this way.
> > >
> >
> > The same could be said for the other approach.  You could easily have,
> >
> > task 'shell' => 'myproject:shell:jirb'
> >
> > in your project and be done with it.
> >
> >
> > > Oh, on a syntactic note, Lispers would know the "shell" much better as
> a
> > > REPL.  What's the preferred terminology?  I like shell because it's
> short
> > > and relatively easy to understand, but maybe I'm the minority.  If
> > someone
> > > is expecting the interactive language shell to be called a "REPL", then
> > > they
> > > would probably expect `buildr shell` to be some sort of interactive
> > command
> > > interface to Buildr itself (allowing you to run tasks).  Does this seem
> > > like
> > > a potential problem or should we not fret over it?
> >
> >
> > I think "shell" is the more common and broader name.   And as shown
> above,
> > it's easy to create an alias if you insist on a specific name.
> >
> > alex
> >
>

[Daniel Spiewak]

Update: auto-magical JavaRebel support is now available based on the
following expression:

@rebel_home = ENV['REBEL_HOME'] or ENV['JAVA_REBEL'] or ENV['JAVAREBEL'] or
ENV['JAVAREBEL_HOME']

This can point to the directory or the javarebel.jar file.  In either case,
the rebel_home method will figure out what's going on and compensate
accordingly.  All of the JVM launch differences are encapsulated in the
rebel_args and rebel_props(project) methods in the Buildr::Shell::JavaRebel
module.

With this support, it was pretty easy to enable JavaRebel launching of the
Scala shell and the Clojure shell.  This is really neat, because it means
that in both cases you get an almost-Lisp-like dynamic programming
environment with any vanilla Java, Scala or Groovy project.  JIRB also now
has support, but that was a little tricky since the JRuby launch process is
more involved.  Basically, if JRUBY_HOME is set, then that installation will
be used.  Otherwise, jruby-complete 1.1.6 will be downloaded and used
instead (this option is not preferred since it's slower).  It looks like
java/jruby.rb does some magic for when Buildr is run under JRuby; I haven't
quite figured that out yet.

Anyway, because the JIRB launch code has to basically replicate the
`bin/jruby` script, it's a lot more complicated and (thus) more prone to
bugs across different platforms.  Seems to work fine on Mac, but additional
testing is needed.

Daniel

On Tue, Jan 6, 2009 at 1:34 PM, Daniel Spiewak <djspiewak@...> wrote:

> Oh I see, allow the task to be project local, just don't define the
> local_task alias.  That would work, but again it's not as magical.
>
> Daniel
>
>
> On Tue, Jan 6, 2009 at 1:07 PM, Alex Boisvert <boisvert@...>wrote:
>
>> On Tue, Jan 6, 2009 at 10:50 AM, Daniel Spiewak <djspiewak@...>
>> wrote:
>>
>> > > Yes, but I only have to do it once when I write the buildfile. All the
>> > > times I run the shell, I don't have to cd into a specific directory,
>> > > or remember the qualified task name. So if you don't need different
>> > > shells for different projects (in the same build), overall there's
>> > > much less effort setting it up this way.
>> >
>>
>> The same could be said for the other approach.  You could easily have,
>>
>> task 'shell' => 'myproject:shell:jirb'
>>
>> in your project and be done with it.
>>
>>
>> > Oh, on a syntactic note, Lispers would know the "shell" much better as a
>> > REPL.  What's the preferred terminology?  I like shell because it's
>> short
>> > and relatively easy to understand, but maybe I'm the minority.  If
>> someone
>> > is expecting the interactive language shell to be called a "REPL", then
>> > they
>> > would probably expect `buildr shell` to be some sort of interactive
>> command
>> > interface to Buildr itself (allowing you to run tasks).  Does this seem
>> > like
>> > a potential problem or should we not fret over it?
>>
>>
>> I think "shell" is the more common and broader name.   And as shown above,
>> it's easy to create an alias if you insist on a specific name.
>>
>> alex
>>
>
>

[Daniel Spiewak]

Right, that's what I understood you to mean.  I guess I just didn't echo it
back correctly.  :-)

Daniel

On Tue, Jan 6, 2009 at 1:40 PM, Alex Boisvert <boisvert@...> wrote:

> Sorry, I wasn't clear.
>
> In my example, I was defining a top-level task "shell" that would be linked
> to a project's specific shell task.
>
> That way, you could do "buildr shell" instead of "buildr myproject:shell"
> or
> "buildr myproject:shell:jirb"
>
> alex
>
>
> On Tue, Jan 6, 2009 at 11:34 AM, Daniel Spiewak <djspiewak@...>
> wrote:
>
> > Oh I see, allow the task to be project local, just don't define the
> > local_task alias.  That would work, but again it's not as magical.
> >
> > Daniel
> >
> > On Tue, Jan 6, 2009 at 1:07 PM, Alex Boisvert <boisvert@...>
> > wrote:
> >
> > > On Tue, Jan 6, 2009 at 10:50 AM, Daniel Spiewak <djspiewak@...>
> > > wrote:
> > >
> > > > > Yes, but I only have to do it once when I write the buildfile. All
> > the
> > > > > times I run the shell, I don't have to cd into a specific
> directory,
> > > > > or remember the qualified task name. So if you don't need different
> > > > > shells for different projects (in the same build), overall there's
> > > > > much less effort setting it up this way.
> > > >
> > >
> > > The same could be said for the other approach.  You could easily have,
> > >
> > > task 'shell' => 'myproject:shell:jirb'
> > >
> > > in your project and be done with it.
> > >
> > >
> > > > Oh, on a syntactic note, Lispers would know the "shell" much better
> as
> > a
> > > > REPL.  What's the preferred terminology?  I like shell because it's
> > short
> > > > and relatively easy to understand, but maybe I'm the minority.  If
> > > someone
> > > > is expecting the interactive language shell to be called a "REPL",
> then
> > > > they
> > > > would probably expect `buildr shell` to be some sort of interactive
> > > command
> > > > interface to Buildr itself (allowing you to run tasks).  Does this
> seem
> > > > like
> > > > a potential problem or should we not fret over it?
> > >
> > >
> > > I think "shell" is the more common and broader name.   And as shown
> > above,
> > > it's easy to create an alias if you insist on a specific name.
> > >
> > > alex
> > >
> >
>

[Alex Boisvert-3]

Well, I was not suggesting any change to what you've already done.  I was
just pointing out that if you want something simple (one global shell for a
given project), the configuration is pretty much trivial.

alex

On Tue, Jan 6, 2009 at 11:42 AM, Daniel Spiewak <djspiewak@...> wrote:

> Right, that's what I understood you to mean.  I guess I just didn't echo it
> back correctly.  :-)
>
> Daniel
>
> On Tue, Jan 6, 2009 at 1:40 PM, Alex Boisvert <boisvert@...>
> wrote:
>
> > Sorry, I wasn't clear.
> >
> > In my example, I was defining a top-level task "shell" that would be
> linked
> > to a project's specific shell task.
> >
> > That way, you could do "buildr shell" instead of "buildr myproject:shell"
> > or
> > "buildr myproject:shell:jirb"
> >
> > alex
> >
> >
> > On Tue, Jan 6, 2009 at 11:34 AM, Daniel Spiewak <djspiewak@...>
> > wrote:
> >
> > > Oh I see, allow the task to be project local, just don't define the
> > > local_task alias.  That would work, but again it's not as magical.
> > >
> > > Daniel
> > >
> > > On Tue, Jan 6, 2009 at 1:07 PM, Alex Boisvert <boisvert@...>
> > > wrote:
> > >
> > > > On Tue, Jan 6, 2009 at 10:50 AM, Daniel Spiewak <djspiewak@...
> >
> > > > wrote:
> > > >
> > > > > > Yes, but I only have to do it once when I write the buildfile.
> All
> > > the
> > > > > > times I run the shell, I don't have to cd into a specific
> > directory,
> > > > > > or remember the qualified task name. So if you don't need
> different
> > > > > > shells for different projects (in the same build), overall
> there's
> > > > > > much less effort setting it up this way.
> > > > >
> > > >
> > > > The same could be said for the other approach.  You could easily
> have,
> > > >
> > > > task 'shell' => 'myproject:shell:jirb'
> > > >
> > > > in your project and be done with it.
> > > >
> > > >
> > > > > Oh, on a syntactic note, Lispers would know the "shell" much better
> > as
> > > a
> > > > > REPL.  What's the preferred terminology?  I like shell because it's
> > > short
> > > > > and relatively easy to understand, but maybe I'm the minority.  If
> > > > someone
> > > > > is expecting the interactive language shell to be called a "REPL",
> > then
> > > > > they
> > > > > would probably expect `buildr shell` to be some sort of interactive
> > > > command
> > > > > interface to Buildr itself (allowing you to run tasks).  Does this
> > seem
> > > > > like
> > > > > a potential problem or should we not fret over it?
> > > >
> > > >
> > > > I think "shell" is the more common and broader name.   And as shown
> > > above,
> > > > it's easy to create an alias if you insist on a specific name.
> > > >
> > > > alex
> > > >
> > >
> >
>