Interactive Shell Support

[Assaf Arkin]

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

Of course there is, you just have to define one for that sub-project,
and it shouldn't take more than a single line.  The question is, what
is the common case: find it, optimize for it. That doesn't mean we
prevent other options, only that we make the common one easier to
access.

Assaf

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

[Assaf Arkin]

On Tue, Jan 6, 2009 at 11:07 AM, 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.

You could. But I'm more concerned with what would actually take place,
read: what people would.

If you offer one shell, assume that's the common option we're
optimizing for, people who need more than one will ask for it. And
it's very easy to explain the path from one shell to two (or more),
and we find a simple solution to make it possible with a single line
of code.

If you offer multiple shells, people just use myproject:shell:jirb.
Some would dig deep enough to discover that they can decorate 'shell'
=> 'myproject:shell:jirb' into each of their buildfiles, and this
simple act saves a lot of typing later. But most people won't do that,
most people will be dealing with lesser quality software.

The question is, what is the common case. If we could decide on that,
we should definitely optimize for the common case.

Assaf

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

On Tue, Jan 6, 2009 at 12:24 PM, Assaf Arkin <arkin@...> wrote:

> The question is, what is the common case. If we could decide on that,
> we should definitely optimize for the common case.


Reframing this way, I would say that my common case would be telling Buildr
exactly which interpreter I want to run with a given project so it knows
which dependencies I want to preload, e.g.,

buildr jirb[myproject]
or
buildr scala[myproject:subproject]

And I would expect Buildr use the test dependencies of the project since
those are usually more complete than the compile dependencies (that usually
include only APIs and no implementation).

alex

[Daniel Spiewak]

Using test.dependencies is an interesting idea.  The problem then is we'll
end up pulling in things like junit:jar, which isn't even remotely necessary
for regular shell stuff.  Also, that raises the question: should we include
_(:target, :test, :classes) as well?  If we do, then we have to depend on
'test:compile', which means that a straight shell launch will take twice as
long on a clean project.

I'm not sure that making tasks like `jirb` top-level is a good idea.  For
one thing, it might lead to name collision down the road (e.g. "scala").
Also, it doesn't "read" (at least to my eyes) like launching a shell.
"buildr scala" almost looks like you're building a new version of Scala
itself.  I think that "buildr shell:scala" or even "buildr shell[scala]" is
more clear what's actually going on.

I agree that we need to decide what the common case is and optimize that.
I'll try to solicit some wider community input on the feature; we'll see
what we get.

Daniel

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

> On Tue, Jan 6, 2009 at 12:24 PM, Assaf Arkin <arkin@...> wrote:
>
> > The question is, what is the common case. If we could decide on that,
> > we should definitely optimize for the common case.
>
>
> Reframing this way, I would say that my common case would be telling Buildr
> exactly which interpreter I want to run with a given project so it knows
> which dependencies I want to preload, e.g.,
>
> buildr jirb[myproject]
> or
> buildr scala[myproject:subproject]
>
> And I would expect Buildr use the test dependencies of the project since
> those are usually more complete than the compile dependencies (that usually
> include only APIs and no implementation).
>
> alex
>

[Daniel Spiewak]

Posed the question to the community at large (all five of my readers):
http://www.codecommit.com/blog/java/hacking-buildr-interactive-shell-support

With any luck, we'll get some feedback indicating general feeling on this
subject.

Daniel

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

> Using test.dependencies is an interesting idea.  The problem then is we'll
> end up pulling in things like junit:jar, which isn't even remotely necessary
> for regular shell stuff.  Also, that raises the question: should we include
> _(:target, :test, :classes) as well?  If we do, then we have to depend on
> 'test:compile', which means that a straight shell launch will take twice as
> long on a clean project.
>
> I'm not sure that making tasks like `jirb` top-level is a good idea.  For
> one thing, it might lead to name collision down the road (e.g. "scala").
> Also, it doesn't "read" (at least to my eyes) like launching a shell.
> "buildr scala" almost looks like you're building a new version of Scala
> itself.  I think that "buildr shell:scala" or even "buildr shell[scala]" is
> more clear what's actually going on.
>
> I agree that we need to decide what the common case is and optimize that.
> I'll try to solicit some wider community input on the feature; we'll see
> what we get.
>
> Daniel
>
>
> On Tue, Jan 6, 2009 at 2:44 PM, Alex Boisvert <boisvert@...>wrote:
>
>> On Tue, Jan 6, 2009 at 12:24 PM, Assaf Arkin <arkin@...> wrote:
>>
>> > The question is, what is the common case. If we could decide on that,
>> > we should definitely optimize for the common case.
>>
>>
>> Reframing this way, I would say that my common case would be telling
>> Buildr
>> exactly which interpreter I want to run with a given project so it knows
>> which dependencies I want to preload, e.g.,
>>
>> buildr jirb[myproject]
>> or
>> buildr scala[myproject:subproject]
>>
>> And I would expect Buildr use the test dependencies of the project since
>> those are usually more complete than the compile dependencies (that
>> usually
>> include only APIs and no implementation).
>>
>> alex
>>
>
>