Feature parity with the Gradle plugin

[Rahul Muttineni]

The Gradle plugin almost contains all the features you'd ever need to work with Eta.

I'll list below the features missing currently in the SBT plugin:

• DSL for configuring Eta projects
  Gradle allows you to specify configuration for Eta projects within its build.gradle file. Similarly, we should be able to specify Eta project configuration in the build.sbt and the SbtEta plugin should automatically generate a .cabal file in a local build artifact folder and update it as necessary. That .cabal file should then be used to run the build.

  You can read the Gradle plugin docs for how that's accomplished right now:
  https://eta-lang.org/docs/user-guides/gradle-user-guide/basic-configuration/plugin-basics

• REPL task
  There should be a eta-repl command that runs the repl - calling etlas repl is sufficient provided that the stdin of the sbt console can be redirect to etlas repl's stdin.

• Multi-project/module support

  • Consistent Dependencies
    When you have multiple Eta projects in a single SBT build, you must ensure that all the dependencies are consistent (using the same version for a given package). The gradle plugin accomplishes this by iterating through all the Eta projects in the build, collecting all their dependencies, And generation a "fake" .cabal file (with pretty much all fields set to default other than build-depends which should list all the collected dependencies) along with a "fake" cabal.project file (for git dependencies) and using etlas freeze against those.
  • In-build Eta dependencies
    Say you have two Eta projects A and B in a build such that B depends on A. You should ensure that the interface file for B is passed on to A. The way you do this is by generating a stub package database with the package conf file that will specify where to find the interface file and add this package database. You can see the Gradle plugin for how that's done (they're called Project dependencies). The easiest way to see this setup is to create a multi-module gradle project, built it, and inspect the build directory. There should be an example in the examples folder of the repo.

• Etlas Configuration
  There should be a way to configure the etlas version to use and it should be downloaded automatically and stored in a cache directory. See this for the url structure.

I'll keep updating this as I remember what else needs to be done.

Cc: @Romastyi

[Rahul Muttineni]

@Romastyi I've updated the original post with additional things that need to be done. The Etlas Configuration task should take priority, and the other one is for advanced usage (multiple Eta projects in an SBT build with optional dependencies amongst themselves).

[romastyi]

The original gradle plugin has one more feature: checker for default-language and default-extensions values by exploring them using eta. Additionally, it can be useful to add command, which will show all available values for these sections to user.

[romastyi]

@rahulmutt Is it useful to add the ability to specify several executables and test suites for Eta project? As far as I know, cabal allows it.

[Rahul Muttineni]

@Romastyi Both your suggestions sound useful, go ahead!

[Rahul Muttineni]

@Romastyi has finished this so all that remains is a release of the sbt-eta plugin.

[romastyi]

@rahulmutt do you have any plans on release version of plugin?

[Rahul Muttineni]

@Romastyi Yes, I'll see if I can finish up the docs and release it by the weekend.

[romastyi]

@rahulmutt Oh, it's wonderful! If you need any help from me let me know.

[Rahul Muttineni]

I have just released 0.3.0 that supports recent versions of Etlas.

I'll close this issue once the docs have been updated as well.