sbt server: querying task values

[laughedelic]

problem

In the current sbt server implementation it's possible either to query a setting (sbt/setting) or to execute an arbitrary "command" (sbt/exec).

The purpose of settings is to store some static values and with sbt/setting client receives the value of the setting. On the contrast tasks get evaluated every time you query them and most of the time (?) they are used for the side effects they produce. In such cases client can use sbt/exec to run a task.

But some tasks are useful exactly because of the values they store, for example: scalacOptions, credentials, sources, dependencyClasspath, etc. And currently there is no way to query those values: sbt/setting works only for setting keys and sbt/exec only logs output, but doesn't return a value.

suggestion

I suggest to add sbt/task request (or probably better improve sbt/exec) to run tasks and retrieve their values. It's similar to sbt/setting, but runs the task like sbt/exec.

I think that changing sbt/exec response is better because it allows clients to use the same request and decide whether they received what they wanted or not (current response is an ExecStatusEvent). Introduction of a new request IMO makes it more complicated: either try and fail or check sbt version somehow to decide whether it's supported.

notes

This has been discussed a bit on Gitter some time ago: https://gitter.im/sbt/sbt-contrib/archives/2017/10/13
And here is the "conclusion":

Simon Schäfer @sschaef Oct 13 2017 10:50
sbt/exec doesn't return anything to the client right now
it just executes the task

Dale Wijnand @dwijnand Oct 13 2017 10:53
well that's not right at all
I mean, that's not what should be happening.

Also a later mention of the same problem: https://gitter.im/sbt/sbt-contrib?at=59efc01119147ac323189a1e

[dwijnand]

here's some more thoughts:

not all task return values are always interesting, for instance compile has an Analysis, that's probably a waste of CPU and bandwidth to serialise down the line every time.

so maybe (not sure) we _should_ introduce a sbt/task request, and that one returns the json value. maybe we should unify to sbt/key so it does setting keys too. (I think @olafurpg mentioned something about getting strings instead of formatted JSON)

[olafurpg]

I agree tasks like compile are less interesting for sbt/task. The main ones I'm personally interested in are

• dependencyClasspath
• scalacOptions
• sources
• (maybe) updateClassifiers

Those should be fine to serialize to JSON.

[eed3si9n]

Here's a PR to make server extensible so you can add your won method to respond from a command - https://github.com/sbt/sbt/pull/5207