Circumventing the common declaration of addPlugins

[huntc]

Given the proposed AutoPlugin mechanism where plugins are required to be added, it'd be nice to have a short cut to the following common expressions in build.sbt:

import com.typesafe.sbt.web.SbtWeb

lazy val root = project.in(file(".")).addPlugins(SbtWeb)

For example, if the project is a single module then may be sbt's processing of build.sbt can be magical and automatically perform the above. Why else would you call addSbtPlugin from plugins.sbt if your single module project wasn't going to use it?

Further to the above, and orthogonal, perhaps a short cut to the expression could be provided e.g.:

lazy val root = project.current.addPlugins(SbtWeb)

My major concern though is that all build.sbt files will have at least 3 extra lines over what they used to have. It isn't a massive concern, but if we are able to address it then I think it'll make a good UX.

[eed3si9n]

We want to do this, but it's actually pretty hard to do this safely. Ideally we should have a read-only reference to the rootProject since sbt always supplies one. For now we are punting it to the future.

[huntc]

OK, but can we please at least have project.current? .in(file(".")) is damn ugly and often repeated.

[jsuereth]

it's not true that sbt always supplies one. project.current implies things we couldn't support.

e.g. in a project build structure:

project/
   ...
build.sbt
projectA/
    build.sbt
projectB/
    build.sbt

project.current should refer to the local directory of the .sbt file. However, we don't have a safe way to do that.

Adding a rootPlugin method is possible, but leads to issues if someone re-uses that method more than once.

What about a project.in(cwd) option? That's far less of a risk.

[huntc]

project.in(cwd) is a definite improvement. @jroper - what'd think?

[eed3si9n]

By the way, officially we're using dot notation or infix? I always write (project in file(.)) following @jsuereth's Coding in Style talks.

[huntc]

Unsure about "officially"... There's nothing in our internal plugin coding guidelines. :-)

[huntc]

...but you're probably correct - I should use the project in cwd form. Thus:

lazy val root = (project in cwd).addPlugins(SbtWeb)

... is that what you're recommending?

[eed3si9n]

To me (project in file(".")) or (project in cwd) reads better.

[huntc]

@jsuereth and @eed3si9n - I've received two comments on this one now since Play 2.3-M1. The commonality is a desire to express:

lazy val root = (project in cwd).addPlugins(SbtWeb)

as just:

addPlugins(SbtWeb)

[julienrf]

just:

addPlugins(SbtWeb)

Indeed, such a shortcut would be very convenient.

[jsuereth]

Yeah, I think there may be a way to do it, but we haven't ironed out the best mechanism. My goal is to avoid having to load settings twice, so when we figure out how to do that and a have a nicer API, it'll be there.

[huntc]

Thanks Josh. In terms of timing I think we need to have something before Play 2.3-RC1 which is due at the end of April. Do you think that's achievable?

I suspect that we will receive too many complaints otherwise.

[jsuereth]

@huntc Not sure. We'll see what we can do, it depends on how invasive it is to add.

[huntc]

We could re-instate Play's playJavaSettings and playScalaSettings or some other alias just for Play, but I'd prefer not to...

[jroper]

Perhaps (project in cwd).addPlugins(PlayScala) reads better, but project.in(cwd).addPlugins(PlayScala) writes better...

Ok... I wanna configure my project...

project

Right, I want the project in the current working directory

project in cwd

Now I want to add a plugin to it

project in cwd.ad

crap...

*backspace*
*backspace*
*backspace*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
*back arrow*
 (
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
*forward arrow*
 ).addPlugins(PlayScala)

Happens to me every time.

[jroper]

By the way, we could provide this in Play:

lazy val root = playScalaRootProject

playScalaRootProject would be an auto import from the Play plugin:

def playScalaRootProject = (project in cwd).addPlugins(PlayScala)

[jsuereth]

We decided against something like that because people might think they can call it twice.

Maybe if it were called createPlayScalaRootProject.

IN any case, I'm debating adding addPlugins/disablePlugins directly to the build.sbt dsl...

[jsuereth]

OK, so I think the current thinking is we can add a hook in the build.sbt file that lets you add project manipulations against the same project referred to by ThisProject using ThisProject

SO, concretely, a build.sbt for dead simple play project would be:

ThisProject.enablePlugins(PlayScala)  // Assuming we rename add -> enable

ThisProject disablePlugins (LameJoshPlugin)

Because no one wants any of my plugins.

The DSL grammr would then look sort of like this :

import :=  "import" restOfImport EOL
definition := ( "val" | "def" | "lazy val" ) restofScalaExpression
projectManipulation := "ThisProject" restofScalaExpression
setting := scalaExpression
dslLine :=  (definition | projectManipulation | setting) blankLine
buildSbt := import*  dslLine*

Any expression starting with ThisProject is wrapped as:

{ ThisProject: Project => <expr> }

Then we store these functions for each .sbt file in a sequence and apply them to the appropriate projects after load/discovery of .scala + .sbt build files but before applying settings (and autoplugins).

This type of transformation won't be supported in build.scala (nor does it make any sense because in build.scala you already have access to the Project instance directly and just call functions on it).

The reasoning behind ThisProject is that it mirrors the ThisProject usable in the setting DSL, so the term isn't overloaded in a confusing way.

[huntc]

This looks like the implementation details of sbt leaking through into the UX. I understand that we're trying to attain binary compatibility, but perhaps the version should be 0.14 if it is getting in the way.

My problem is that all settings here are w.r.t. to the current project... and then, for one group of declarations, you must use ThisProject. That doesn't grok IMHO.

[jsuereth]

It's not a binary compatibility issue necessarily, but how we do loading. The set of enabled plugins is not a setting for the build, because you need its value to determine what settings are used.

There's a class of these "thing which are used to determine which settings are loaded" of which enabledPlugins belongs. What I'm trying to do is make it feel like a setting even if it isn't.

ThisProject.<thing which helps define how settings are loaded> matches the .scala mechanism of:

object SomeBuild extends Build {
   val foo = project.<thing which helps define how settings are loaded>
}

So, even if we were on version 0.14, the issue remains the same.

[havocp]

is it possible to special case "enablePlugins" and "disablePlugins" so you don't need the ThisProject in front? Then the only remaining "noise" is that we have both addSbtPlugin and enablePlugins, but that noise is sort of inevitable since we want to control plugins per-project instead of per-build.

[jsuereth]

Yeah, it's possible, just ugly, but Maybe that's what we need to do.

[havocp]

A problem with ThisProject is that the name doesn't really communicate the difference between things that have ThisProject in front and things that don't. That is, everything in a build.sbt is already scoped to this project automatically... so why do some have ThisProject? It seems confusing to have ThisProject when everything in the file is already for this project. People could easily start to think that regular settings are not for this project.

Project.current is a little bit prettier since it conveys (to me anyway) that there's a "project object instance" that I need to get a handle to. And it doesn't look like a key scope; ThisProject looks like the scope syntax, but isn't. Still, Project.current probably doesn't make much sense to people who aren't familiar with the .scala setup.

If we want to communicate in the user model that some things are "outside of" settings and happen before we add the settings, then maybe some syntax that better conveys that idea, but I don't know what it would be... maybe a project {} preamble block?

But do we even need to communicate that I wonder? I'm not sure it matters that much to people that we process enablePlugins before we load settings. Mostly things should just work in a way that makes sense....

[huntc]

So in future:

lazy val root = (project in file(".")).addPlugins(SbtWeb)

will become:

enablePlugins(SbtWeb)

?

[jsuereth]

Note: This required completely redoing the core of the "Load.scala" algorithm for grabbing Project instances from config files, but the meat of it is here: 52e3e6f

Once I flush out any extraneous issues, I'll issue a pull request.

[huntc]

Awesome work guys!

[jaceklaskowski]

BTW, lazy val root = (project in file(".")).addPlugins(SbtWeb) can also be lazy val root = project in file(".") addPlugins SbtWeb (that doesn't necessarily help in IDE or @jroper)