Unification of sbt shell notation and build.sbt DSL

Tooling
16

@OlegYch

Is it necessary to flip the order to support / syntax?

As many have noted / has a strong notion of contains-a relationship, so flipping will be confusing.

How about ‘key in axis in axis in axis’ syntax?

Solution 2 #3259 actually supports both key in (proj, Config, intask) notation and key in axis in axis in axis.

Having said that, I generally recommend using in with tuple because you could write nonsensical scopes like scalacOptions in Compile in Test or something order dependent:

  • scalacOptions in Compile in Global
  • scalacOptions in Global in Compile

@olafurpg

Can option 2 support the same nice tab completion as the current shell syntax? Tab completion is very important for me to discover/explore builds.

Solution 2 will have tab completion for unscoped keys:

> tes[tab]
> test
> test[tab]
> test
::                   test:                testForkedParallel   testFrameworks       testGrouping         testListeners        testLoader           testOnly             testOptions
testQuick

I think it covers the case for most usages. The current parser and the slash syntax will have the advantage when we start to do scoping by Test for example, but these are relatively exotic usages, I think.

I really like the new proposed slash syntax, but I’m afraid the migration cost would only further delay sbt v1.0 adoption.

As demonstrated by the fact that I first sent the PRs to 0.13 branch, I was able to overlay these solutions on top of existing shell and build.sbt DSL without breaking source or binary compatibility. The decision to drop the old shell parser and the in method in build.sbt is a knob we can tweak. There seems to be “Keep Old in 1.0” and “Drop Old in 1.0” camps.

@nadavwr

Maybe a ‘/:’ for the same evaluation order as ‘in’?

Not sure what this suggestion is in response for, but /: means foldLeft, and it just makes simple / more cryptic.

@tpolecat

What does the DSL desugar to? I want to know what the normal form is before trying to figure out what the sugar needs to look like.

The topic on this thread is string representation of a data structure called ScopedKey in sbt shell and unifying that with setting/task keys in build.sbt.

The implementation of setting key’s in “operator” is actually a method Structure.scala#L38 that takes a Scope as an argument and returns a new setting key.
There are a bunch of overloads for in methods that creates Scope, which is just a case class consisting of scope axes.

2 Likes