Task or command?

[Heiko Seeberger]

Hi,

When should we use a task and when a command?

Currently I am asking myself this question, because I am thinking about porting bnd (OSGi) to sbt 0.11.

Are there some easy rules of thumb?

Thanks,

Heiko

--

Heiko Seeberger
Twitter: hseeberger
Blog: heikoseeberger.name
Company: Typesafe - Enterprise-Grade Scala from the Experts
Author of Durchstarten mit Scala, a German tutorial-style Scala book

[Jason Zaugg]

The rule of thumb is: use tasks. These are the normal building blocks of a build, producing some product and/or a side-effect based on other tasks and settings.

Commands are useful if you want to modify the state of the build. e.g: you could: change the prompt, reload the project, modify the settings for the loaded projects, control a background process, such as a web container. But you could go your whole life in SBT without needing to write one yourself.

-jason

[Doug Tangren]

On Mon, Oct 3, 2011 at 11:27 AM, Jason Zaugg <jza...@gmail.com> wrote:

The rule of thumb is: use tasks. These are the normal building blocks of a build, producing some product and/or a side-effect based on other tasks and settings.

Commands are useful if you want to modify the state of the build. e.g: you could: change the prompt, reload the project, modify the settings for the loaded projects, control a background process, such as a web container. But you could go your whole life in SBT without needing to write one yourself.

That's my general feeling as well. I think with a little extra work sbt may be able to do away with the task's older brother, command.  I think you can actually, extract state from the build if you wanted so I still get confused as to why you'd need a command in the first place. I have yet to run into a problem that I could not solve with an (input)task.

[Josh Suereth]

I have, sort of.   With things like onLoad and some of Mark's new features, commands may be more unnecessary, but they should be reserved for those who know why they need them :)

[Heiko Seeberger]

> That's my general feeling as well. I think with a little extra work sbt may be able to do away with the task's older brother, command. I think you can actually, extract state from the build if you wanted so I still get confused as to why you'd need a command in the first place. I have yet to run into a problem that I could not solve with an (input)task.

In sbteclipse I had to run one or another task. That's the reason I went for a command. Well, actually Mark guided me all the way …

Would it be possible and make sense to (conditionally) run other tasks from a task?

And what about reloading the current sbt session?

Heiko

[Mark Harrah]

On 10/3/11, Heiko Seeberger <heiko.s...@googlemail.com> wrote:
>> That's my general feeling as well. I think with a little extra work sbt
>> may be able to do away with the task's older brother, command. I think
>> you can actually, extract state from the build if you wanted so I still
>> get confused as to why you'd need a command in the first place. I have yet
>> to run into a problem that I could not solve with an (input)task.
>
> In sbteclipse I had to run one or another task. That's the reason I went for
> a command. Well, actually Mark guided me all the way …

Yes, IDE plugins should be commands in my opinion. The rules of thumb
aren't as clear, but commands provide a high degree of flexibility but
with the requirement of more knowledge of sbt internals.

Tasks are limited in their ability to transform settings and reload
the sbt session. (Yes, technically you can do it with the latest
changes that allow tasks to transform State at the end of task
execution, but it is forcing it and is not a good fit.)

> Would it be possible and make sense to (conditionally) run other tasks from
> a task?

You can do this using flatMap. It isn't really cleaned up and
documented, though.

> And what about reloading the current sbt session?

This kind of advanced build manipulation should be done from commands.
In general, State manipulation is best done by commands. The new
State transformation hooks for tasks that will come in 0.11.1 are
really aimed at tasks preserving state across executions and not
really for something more global.

The bnd plugin should probably define tasks, unless there is some
flexibility it requires that isn't immediately obvious.

-Mark

[Mark Harrah]

While it is true that most plugins will only ever provide tasks and
the "rule of thumb to use tasks" is a good one, commands are more
fundamental than tasks. Projects and tasks are built on top of
commands and the command cycle.

It may help to see the three main execution environments of sbt.
First, there is the launcher, which reads a configuration file to
determine what to retrieve, load, and run. For "sbt", this is the
sbt.xMain class, but it could be sbt.ScriptMain for the script mode
described on Scripts[1].

The next step is the basic command loop, which executes queued
commands that transform State. If you run 'help', you'll see the
user-visible commands. These commands are not hard-coded and can be
replaced. The command concept cannot be replaced by tasks, however.
For example, 'shell' is a command, and a replaceable command at that.
If you want to operate sbt from a web browser[2], you could.

Finally, the project loading command sets up the actual build tool
aspect of sbt: the resolving, building, loading, and running of
projects and the tasks in them. Tasks are hooked into the command
cycle by a command. All of this is implemented on top of commands and
the command loop.

-Mark

[1] https://github.com/harrah/xsbt/wiki/Scripts
[2] for an older sbt version: https://github.com/n8han/pilot