sbt server reboot

[eugene yokota]

hi devs,

wrote "sbt-server reboot" post based on code retreat + some additional hacking: http://eed3si9n.com/sbt-server-reboot

let me know what you think.

-eugene

[Perry Nguyen]

Overall, I like the simplicity, but I have questions and concerns about how this would work:

* Who has responsibility for starting sbt server when using IDE integration?

** If the IDE is responsible for starting the server, how will I as the user have access to full REPL functionality?

** If the IDE is not responsible for starting the server, this will lead to a pretty poor experience of having to manually start/manage multiple things

*** I think gradle is a little more advanced here wrt its tooling API

* Related to the above, since the sbt server might not be started by me, what are the plans for bringing most of the REPL functionality to sbt client?

** Primarily, I want to have access to log messages (perhaps info and more only), inspect, commands and tab completion

* What about console* and reload plugins to get at the meta project from client?

There's probably more things I would like to see as a user, but these came to mind immediately when reading through. Thanks

[eugene yokota]

I'll respond inline.

On Wed, Mar 23, 2016 at 12:30 PM, Perry Nguyen <pfng...@gmail.com> wrote:

Overall, I like the simplicity, but I have questions and concerns about how this would work:

* Who has responsibility for starting sbt server when using IDE integration?

** If the IDE is responsible for starting the server, how will I as the user have access to full REPL functionality?

** If the IDE is not responsible for starting the server, this will lead to a pretty poor experience of having to manually start/manage multiple things

As I covered in my blog post, I envision that the build user could manually start the sbt server, at least initially.

If there are enough interest in the feature, over time things might improve. For example, maybe the IDE can automatically start it for you in a window.

 

*** I think gradle is a little more advanced here wrt its tooling API

There's a whole design/discussion around auto discovery here, which sbt-remote-control + Activator uses - https://github.com/sbt/sbt/wiki/Client-server-discovery-lifecycle

I'm being more cautious this time around.

 

* Related to the above, since the sbt server might not be started by me, what are the plans for bringing most of the REPL functionality to sbt client?

I am side stepping the issue (at least initially) because you are starting the server yourself, and you to get tab completion in the "server" command. Also IDEs can embed a window that runs sbt inside (IntelliJ does this already).

So the following would matter more to the IDE plugins and potential thin clients.

 

** Primarily, I want to have access to log messages (perhaps info and more only), inspect, commands and tab completion

Log messages are important to me too. They will be the first-class citizen in the server world as events.

I think it would make sense to provide custom events for things like inspect command, but not sure if it would be v1 or v1.1.

Tab completion shouldn't matter much unless you're implementing a thin client. Eventually it should be part of the query against the latest state.

* What about console* and reload plugins to get at the meta project from client?

console abstraction is possible. tpolecat/tut (or my own sbt/sbt-pamflet used for "herding cats") can turn a markdown text into Scala REPL.

If a markdown can do it, so can JSON, hopefully. Again, this would be like a v1.1 feature for the thin client.

There are lots of little details like these for the daemon route. As I wrote on the post, my goal is to underengineer the whole thing.

[Naftoli Gugenheim]

On Thu, Mar 24, 2016 at 12:28 AM eugene yokota <eed3...@gmail.com> wrote:

I'll respond inline.

On Wed, Mar 23, 2016 at 12:30 PM, Perry Nguyen <pfng...@gmail.com> wrote:

Overall, I like the simplicity, but I have questions and concerns about how this would work:

* Who has responsibility for starting sbt server when using IDE integration?

** If the IDE is responsible for starting the server, how will I as the user have access to full REPL functionality?

** If the IDE is not responsible for starting the server, this will lead to a pretty poor experience of having to manually start/manage multiple things

As I covered in my blog post, I envision that the build user could manually start the sbt server, at least initially.

If there are enough interest in the feature, over time things might improve. For example, maybe the IDE can automatically start it for you in a window.

 

*** I think gradle is a little more advanced here wrt its tooling API

There's a whole design/discussion around auto discovery here, which sbt-remote-control + Activator uses - https://github.com/sbt/sbt/wiki/Client-server-discovery-lifecycle

I'm being more cautious this time around.

I hope it works out, and we're not just going from one bad extreme to the opposite bad extreme (too overengineered to too underengineered) 

 

* Related to the above, since the sbt server might not be started by me, what are the plans for bringing most of the REPL functionality to sbt client?

I am side stepping the issue (at least initially) because you are starting the server yourself, and you to get tab completion in the "server" command. Also IDEs can embed a window that runs sbt inside (IntelliJ does this already).

Doesn't that rule out the primary use case, "I shouldn't have to open a terminal to use my IDE"?

 

So the following would matter more to the IDE plugins and potential thin clients.

 

** Primarily, I want to have access to log messages (perhaps info and more only), inspect, commands and tab completion

Log messages are important to me too. They will be the first-class citizen in the server world as events.

I think it would make sense to provide custom events for things like inspect command, but not sure if it would be v1 or v1.1.

Tab completion shouldn't matter much unless you're implementing a thin client. Eventually it should be part of the query against the latest state.

* What about console* and reload plugins to get at the meta project from client?

console abstraction is possible. tpolecat/tut (or my own sbt/sbt-pamflet used for "herding cats") can turn a markdown text into Scala REPL.

Well, not an interactive one.

But I don't see how it's different than the question "How can I run my scala app that reads stdin and writes stdout."

 

If a markdown can do it, so can JSON, hopefully. Again, this would be like a v1.1 feature for the thin client.

There are lots of little details like these for the daemon route. As I wrote on the post, my goal is to underengineer the whole thing.

What's the definition of underengineer?

There's probably more things I would like to see as a user, but these came to mind immediately when reading through. Thanks

On Tuesday, March 22, 2016 at 10:19:46 AM UTC-7, eugene yokota wrote:

hi devs,

wrote "sbt-server reboot" post based on code retreat + some additional hacking: http://eed3si9n.com/sbt-server-reboot

let me know what you think.

-eugene

Anyway it's great to see things happening.

(One of the recent troll posts was about sbt being abandoned, and while I'm sure there's lots of behind-the-scenes work, it's good to see something more interesting.)

 

--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CA%2BCq6KST2N_X4fAxC1_gpZ%2BU4LCvgmAW7kiBpoyEs7-K%2B2OLUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[eugene yokota]

On Thu, Mar 24, 2016 at 3:38 AM, Naftoli Gugenheim <nafto...@gmail.com> wrote:

If a markdown can do it, so can JSON, hopefully. Again, this would be like a v1.1 feature for the thin client.

There are lots of little details like these for the daemon route. As I wrote on the post, my goal is to underengineer the whole thing.

What's the definition of underengineer?

Designing of a product to be less robust, convenient, flexible, featureful than is necessary for its use cases.

One button mouse you want two. Bringing knife to a gun fight.

-eugene

[Perry Nguyen]

Eugene's post inspired me to implement this solution myself atop the current sbt versions and so far, the ergonomics of it feel terrible.

My version can be found at https://github.com/pfn/sbt-simple-server

It's a plugin that should drop in and work seamlessly on 0.13.5+

There is a proof of concept client script written in python and the plugin should enable the server automatically when the plugin is added to the build (it is compatible with a global plugin configuration)