On Tue, Jan 6, 2009 at 10:50 AM, Daniel Spiewak <[email protected]> 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 >
