sbt runEngineDistribution ...args... to build and execute the engine

[JaroslavTulach]

Pull Request Description

Automating the assembly of the engine and its execution into a single task. If you are modifying standard libraries, engine sources or Enso tests, you can launch sbt and then just:

sbt:enso> runEngineDistribution --run test/Tests/src/Data/Maybe_Spec.enso
[info] Engine package created at built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev
[info] Executing built-distribution/enso-engine-...-dev/bin/enso --run test/Tests/src/Data/Maybe_Spec.enso
Maybe:  [5/5, 30ms]
    - should have a None variant [14ms]
    - should have a Some variant [5ms]
    - should provide the `maybe` function [4ms]
    - should provide `is_some` [2ms]
    - should provide `is_none` [3ms]
5 tests succeeded.
0 tests failed.unEngineDistribution 4s
0 tests skipped.

the runEngineDistribution sbt input task makes sure all your sources are properly compiled and only then executes your enso source. Everything ready at a single press of Enter.

Important Notes

To debug in chrome dev tools, just add --inspect:

sbt:enso> runEngineDistribution --inspect --run test/Tests/src/Data/Maybe_Spec.enso
E.g. in Chrome open: devtools://devtools/bundled/js_app.html?ws=127.0.0.1:9229/7JsgjXlntK8

everything gets build and one can just attach the Enso debugger.

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the
  Scala,
  style guides.
• All code has been tested:
  • Unit tests have been written where possible.

[JaroslavTulach]

CCing Michal, as this enhancement shall work fine with

enso$ ./run backend sbt

as well. E.g. it is not just another helper script, but a step towards ultimate integration with CI tools. Overall I tend to start believing that download related task shall be solved by ./run and interactive tasks for engine developers shall be coded as sbt tasks. The ./run backend sbt would then be the glue to join these two approaches together.

[jdunkerley]

Nice - could we have this on buildStdLib... as well?

[Akirathan]

Does not suite my personal workflow, as I use custom key bindings for engine building in IntelliJ, but is very helpful nonetheless.

[4e6]

I suggest moving this logic in the DistributionPackage module.

[JaroslavTulach]

I suggest moving this logic in the DistributionPackage module.

Done in 7a3697d

[JaroslavTulach]

Nice - could we have this on buildStdLib... as well?

Adding this execution to a single task isn't hard - see the current changes in build.sbt - just add new task and set the dependency up.

Adding this to all the various tasks for building libraries requires some sbt trickery I don't have will to investigate. Ideally (as has been suggested elsewhere) we fix the dependency check of buildEngineDistribution and make it fast on its own. Then runEngineDistribution would be good enough.

[radeusgd]

I know this was already there, but technically this executable is the runner. The launcher is a separate project. Can we rename it to reduce possible confusion?

[radeusgd]

This is very cool 🎉