buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Spiewak" <djspie...@gmail.com>
Subject Re: Interactive Shell Support
Date Tue, 06 Jan 2009 18:50:51 GMT
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message