sbt 1.0 proposal: Build Level

[eugene yokota]

Hi,

I wrote up a feature proposal for sbt 1.0 called Build Level - https://github.com/sbt/sbt/wiki/User-Stories:-Build-Level

It's a way of declaring certain settings as optional and/or explicitly degrading settings when dealing with nightlies and RCs.

What do you guys think?

-eugene

[Christopher Hunt]

My immediate reaction is against splitting build.sbt into more files. I think that we should strengthen the emphasis on build.sbt providing an at-a-glance comprehension of the project's build.

I also think that project sbt files should be able to expressed within build.sbt for the same reason, but perhaps that is a different, but related conversation.

Kind regards
Christopher

[Aleh Aleshka]

Do you mean dealing with nightlies of sbt/plugins ?
Imo this is a rather edge usecase, not warranting introducing a new concept...
How do buildlevels relate to scopes? they seem to be confusingly similar, yet not identical...

Thanks, Aleh

[eugene yokota]

I had RCs and snapshots of Scala and/or libraries built on top of them in my mind,

but scaling down the build could be useful for dealing with sbt and its plugin ecosystem too.

When you have to upgrade your sbt version beyond the original author's sbt version.

Often times, when I git clone someone else's library, I'm only interested in publishing it locally, so I wouldn't care if releasing related plugins do not work.

-eugene

--
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/6d23b422-a49e-4da4-aef1-040f2ae74701%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Aleh Aleshka]

Unrelated to this discussion, but i think we should emphasize *.scala format. It already provides the best possible representation of your project configuration and is not limited in any way.
The perceived simplicity of *.sbt format hides important concepts which are easier to comprehend when they are not obstructed by custom syntax and implicit rules.

[eugene yokota]

On Sun, Mar 23, 2014 at 4:49 PM, Christopher Hunt <christop...@typesafe.com> wrote:

My immediate reaction is against splitting build.sbt into more files. I think that we should strengthen the emphasis on build.sbt providing an at-a-glance comprehension of the project's build.

Interesting point. I'd definitely consider providing a mechanism of not splitting up build.sbt too then.

What do you think about being able to mark certain settings as "test", "publish", "idea" (optional)?

I also think that project sbt files should be able to expressed within build.sbt for the same reason, but perhaps that is a different, but related conversation.

It's definitely related because my proposal of the build level affects plugins too.

-eugene 

[Josh Suereth]

I think perhaps we should be able to mark level at the plugin level (when depending on them).   If, maybe, we had a way to denote settings as "uneeded" and we could ensure nothing which depended on uneeded settings was loaded, we could avoid the issues we have.

A lot of the "i don't need that plugin" issues come right during Ivy resolution time.  I see the build-levels helping denote which settings rely on which plugins, but perhaps we can do better in some fashion?

I think Alan has a point that we should expose this in the .scala syntax too if we can.

I like the idea of build levels, in the sense that you don't need the ENTIRE build loaded to get work done on a project.  

The one thing that still limits .sbt files i the ability to autocomplete them in IDEs.  Otherwise, you can actually accomplish very similar things in both .scala + .sbt.  I'm unaware of any limitations besides mandatory whitelines (which I think we can successfully get rid of).

[eugene yokota]

On Mon, Mar 24, 2014 at 9:49 AM, Josh Suereth <joshua....@gmail.com> wrote:

I think perhaps we should be able to mark level at the plugin level (when depending on them).   If, maybe, we had a way to denote settings as "uneeded" and we could ensure nothing which depended on uneeded settings was loaded, we could avoid the issues we have.

Yea. sbt.buildLevel should propagate down to metabuilds. See [2]

A lot of the "i don't need that plugin" issues come right during Ivy resolution time.  I see the build-levels helping denote which settings rely on which plugins, but perhaps we can do better in some fashion?

Right. If project/publish.sbt is denoted as `buildLevel in ThisSet := publish` and the build user says "-publish", sbt-assembly won't be loaded. That exactly is the design.

Currently there's no mechanism to link between plugins and their associated setting overrides.

Since "-publish" des not bring in sbt-assembly, but somewhere in your build.sbt you still have `jarName in assembly := "foo.jar"`, it's not going to compile.

So, at this point, we need sbt-assembly settings under helloworld/publish.sbt so it too can declare the build level.

I think Alan has a point that we should expose this in the .scala syntax too if we can.

All the above benefits are tricker to make it happen with .scala since it's in a single compilation unit.

I basically need to tell the compiler not to compile certain block of code under certain conditions. Annotation and compiler plugin maybe? 

  [2]: https://github.com/sbt/sbt/wiki/User-Stories:-Build-Level#user-story-setting-the-build-level-of-plugins