[sbt 1.0] sbt.Build => sbt.internal.BuildDef #2524

Merged
merged 70 commits into from Mar 29, 2016

Conversation

Projects
None yet
@eed3si9n
Member

eed3si9n commented Mar 29, 2016

This change removes sbt.Build from the common build classpath there by removing Build.scala dialect of the build definition. Most scripted tests are ported over to build.sbt.

before (a typical project/Build.scala)

import sbt._
import Keys._
import Import._

object build extends Build {
    override def settings = super.settings ++ Seq(scalaVersion := "2.11.7")

    val defaultSettings = Seq(
        libraryDependencies <+= scalaVersion("org.scala-lang" % "scala-reflect" % _ )
    )

    lazy val root = Project(
       base = file("."),
       id = "macro",
       aggregate = Seq(macroProvider, macroClient),
       settings = Defaults.defaultSettings ++ defaultSettings
    )

    lazy val macroProvider = Project(
       base = file("macro-provider"),
       id = "macro-provider",
       settings = Defaults.defaultSettings ++ defaultSettings
    )

    lazy val macroClient = Project(
       base = file("macro-client"),
       id = "macro-client",
       dependencies = Seq(macroProvider),
       settings = Defaults.defaultSettings ++ defaultSettings
    )
}

after (sbt 0.13 multi-project build.sbt)

lazy val commonSettings = Seq(
  libraryDependencies += "org.scala-lang" % "scala-reflect" % scalaVersion.value
)

lazy val root = (project in file(".")).
  aggregate(macroProvider, macroClient).
  settings(inThisBuild(List(
      scalaVersion := "2.11.7"
    )),
    commonSettings
  )

lazy val macroProvider = (project in file("macro-provider")).
  settings(
    commonSettings
  )

lazy val macroClient = (project in file("macro-client")).
  dependsOn(macroProvider).
  settings(
    commonSettings
  )

note

As you can see, project/Build.scala and build.sbt are not that different.

The build users can still define classes and objects in project/*.scala for instance to organize dependencies. I'm only deprecating the Build.scala style of build definitions.

/review @dwijnand, @jsuereth, @Duhemm

eed3si9n added some commits Mar 28, 2016

sbt.Build => sbt.internal.BuildDef
sbt.Load => sbt.internal.Load

@sjrd sjrd referenced this pull request in scala-js/scala-js Mar 30, 2016

Closed

Migrate away from our Build.scala build definition #2311

@huitseeker

This comment has been minimized.

Show comment
Hide comment
@huitseeker

huitseeker Mar 30, 2016

This would instantly break many major projects (e.g. Spark, ScalaJs, Scalatest ...) in the Scala ecosystem.
Please provide (& test) an automated tool for translation.

This would instantly break many major projects (e.g. Spark, ScalaJs, Scalatest ...) in the Scala ecosystem.
Please provide (& test) an automated tool for translation.

@fommil

This comment has been minimized.

Show comment
Hide comment
@fommil

fommil Mar 30, 2016

most people do not set scalaVersion := "2.11.7" this way. They'd just put it flat at the same level as your vals. There is also no reason why those lazy vals can't go into the build.scala, nor is there anything stopping people from using the "bad" Project constructors from .sbt files. Why not just make the non-trivial constructors to Project private?

fommil commented Mar 30, 2016

most people do not set scalaVersion := "2.11.7" this way. They'd just put it flat at the same level as your vals. There is also no reason why those lazy vals can't go into the build.scala, nor is there anything stopping people from using the "bad" Project constructors from .sbt files. Why not just make the non-trivial constructors to Project private?

@eed3si9n eed3si9n changed the title from sbt.Build => sbt.internal.BuildDef to [sbt 1.0] sbt.Build => sbt.internal.BuildDef Mar 30, 2016

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Mar 30, 2016

Member

Please note that this PR is for sbt 1.0.x, and we've hinted this for over a year.

This page discusses the newest multi-project .sbt build definition, which combines the strength of the two older flavors, and is suitable for all cases.

We are removing Build.scala because having three dialects to describe the build is a source of confusion for many users, especially in combination with the plugins.

When the users are confused, they come talking to sbt developers and plugin authors, and this is one way for me personally to make the supporting of sbt and plugins easier. The moment we shipped the auto plugin (with auto import) feature, the days of Build.scala were numbered.

I know many of the power users like Build.scala, but I haven't heard compelling argument to reverse the above position for sbt 1.0. As per upgrading, I just converted ~70 integration tests manually, and it wasn't too bad.

Member

eed3si9n commented Mar 30, 2016

Please note that this PR is for sbt 1.0.x, and we've hinted this for over a year.

This page discusses the newest multi-project .sbt build definition, which combines the strength of the two older flavors, and is suitable for all cases.

We are removing Build.scala because having three dialects to describe the build is a source of confusion for many users, especially in combination with the plugins.

When the users are confused, they come talking to sbt developers and plugin authors, and this is one way for me personally to make the supporting of sbt and plugins easier. The moment we shipped the auto plugin (with auto import) feature, the days of Build.scala were numbered.

I know many of the power users like Build.scala, but I haven't heard compelling argument to reverse the above position for sbt 1.0. As per upgrading, I just converted ~70 integration tests manually, and it wasn't too bad.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Mar 30, 2016

Member

I know that every build is different in their own way, but the Build trait is all of 5 properties: https://github.com/sbt/sbt/blob/v0.13.11/main/src/main/scala/sbt/Build.scala#L11-L22

And converting a build like Scala.js' wasn't that hard (pending Jenkins passing :-D): scala-js/scala-js#2312

Member

dwijnand commented Mar 30, 2016

I know that every build is different in their own way, but the Build trait is all of 5 properties: https://github.com/sbt/sbt/blob/v0.13.11/main/src/main/scala/sbt/Build.scala#L11-L22

And converting a build like Scala.js' wasn't that hard (pending Jenkins passing :-D): scala-js/scala-js#2312

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Mar 30, 2016

Contributor

@eed3si9n I haven't heard any satisfying suggestion on how to avoid spreading build files across multiple folders yet.

Contributor

soc commented Mar 30, 2016

@eed3si9n I haven't heard any satisfying suggestion on how to avoid spreading build files across multiple folders yet.

@melezov melezov referenced this pull request in scala-ide/scalariform Mar 30, 2016

Merged

Refactored project build, bumped dependencies #219

@larroy

This comment has been minimized.

Show comment
Hide comment
@larroy

larroy Mar 30, 2016

Contributor

Why not do the opposite and remove the weird DSL syntax so build files are done in Scala?

Contributor

larroy commented Mar 30, 2016

Why not do the opposite and remove the weird DSL syntax so build files are done in Scala?

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Mar 30, 2016

Member

@soc Multi-project build.sbt can describe the entire build in one file. Are you saying you're against removing Build.scala because someone can commit build.sbt to a subproject directory? That doesn't make sense.

Member

eed3si9n commented Mar 30, 2016

@soc Multi-project build.sbt can describe the entire build in one file. Are you saying you're against removing Build.scala because someone can commit build.sbt to a subproject directory? That doesn't make sense.

@pfn

This comment has been minimized.

Show comment
Hide comment
@pfn

pfn Mar 30, 2016

how would one auto-generate builds/projects in the new manner? android-gradle-build relies on being declared as object build extends android.GradleBuild

this allows automatically creating an sbt project from a gradle project without any additional configuration.

pfn commented Mar 30, 2016

how would one auto-generate builds/projects in the new manner? android-gradle-build relies on being declared as object build extends android.GradleBuild

this allows automatically creating an sbt project from a gradle project without any additional configuration.

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Mar 31, 2016

Contributor

@eed3si9n Currently my build configurations all look like this:

project/
        build.scala
        build.sbt
        build.properties

Everything is in one, non-project-root directory. It seems like this will stop working with the proposed changes?

Contributor

soc commented Mar 31, 2016

@eed3si9n Currently my build configurations all look like this:

project/
        build.scala
        build.sbt
        build.properties

Everything is in one, non-project-root directory. It seems like this will stop working with the proposed changes?

@huitseeker

This comment has been minimized.

Show comment
Hide comment
@huitseeker

huitseeker Mar 31, 2016

@eed3si9n I'm not saying there is a compelling argument to be made as to Build.scala being technically better. Nor am I judging whether there was sufficient notice as to the arrival of that change. I don't want to get into that argument.

I'm just saying that considering this breaks large sbt builds for major Scala projects, the writing is on the wall as to the speed at which (at least) these will upgrade.

Please provide (& test) an automated tool for translation, as a way to speed up this process.

@eed3si9n I'm not saying there is a compelling argument to be made as to Build.scala being technically better. Nor am I judging whether there was sufficient notice as to the arrival of that change. I don't want to get into that argument.

I'm just saying that considering this breaks large sbt builds for major Scala projects, the writing is on the wall as to the speed at which (at least) these will upgrade.

Please provide (& test) an automated tool for translation, as a way to speed up this process.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Mar 31, 2016

Member

I'm in the process of upgrading the Scala.js build, and it wasn't hard.

But it would be great if someone would create an automated tool for translation to speed up the process. 👍

Member

dwijnand commented Mar 31, 2016

I'm in the process of upgrading the Scala.js build, and it wasn't hard.

But it would be great if someone would create an automated tool for translation to speed up the process. 👍

@farmdawgnation

This comment has been minimized.

Show comment
Hide comment
@farmdawgnation

farmdawgnation Mar 31, 2016

we've hinted this for over a year.

I haven't seen anyone address this particular remark yet so I feel that I should.

Hinting at a change at a conference is not a satisfactory way of letting your community know that things are changing significantly. Not all of us go to those conferences. Those that do may not attend a session where this is hinted at. Of those that do probably only a percentage catch the actual hint and fully internalize it. If you've truly known about this for a year, sbt 0.13.x should have started surfacing a deprecation warning when it was building a Build.scala project.

Sorry if this comes off a bit rude, but I'm really quite annoyed that hasn't been done anytime in the last year as far as I can tell.

EDIT: Just realized one of those links wasn't a conference but a ML post. Which... okay that's more reasonable. But I do still feel there should have been a deprecation warning.

we've hinted this for over a year.

I haven't seen anyone address this particular remark yet so I feel that I should.

Hinting at a change at a conference is not a satisfactory way of letting your community know that things are changing significantly. Not all of us go to those conferences. Those that do may not attend a session where this is hinted at. Of those that do probably only a percentage catch the actual hint and fully internalize it. If you've truly known about this for a year, sbt 0.13.x should have started surfacing a deprecation warning when it was building a Build.scala project.

Sorry if this comes off a bit rude, but I'm really quite annoyed that hasn't been done anytime in the last year as far as I can tell.

EDIT: Just realized one of those links wasn't a conference but a ML post. Which... okay that's more reasonable. But I do still feel there should have been a deprecation warning.

@karma4u101 karma4u101 referenced this pull request in karma4u101/FoBo Mar 31, 2016

Closed

Move away from Build.scala #71

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Mar 31, 2016

Member

@farmdawgnation You're totally right about deprecation. The next sbt 0.13.x will have the warning (sbt/sbt#2530), and it will be some time until sbt 1.0.x comes out.

Member

eed3si9n commented Mar 31, 2016

@farmdawgnation You're totally right about deprecation. The next sbt 0.13.x will have the warning (sbt/sbt#2530), and it will be some time until sbt 1.0.x comes out.

@muuki88

This comment has been minimized.

Show comment
Hide comment
@muuki88

muuki88 Apr 1, 2016

I like the decision. AutoPlugins where the first step to separate the how / what things are done.
build.sbt files are nice for definitions and simple settings. Your "build-logic" can go in separate plugins.

We introduced this in our company and people where starting to actually like sbt, contributing to our company wide autoplugins, and reducing the build definitions in our projects from multipe build.sbt files and Build.scala to a single, very concise build.sbt.

A migration is straightforward. You put your logic and default settings into autoplugins (e.g. http calls to jenkins for latest versions, nexus/artifactory credentials, and so on). Then you create a build.sbt where you should only use something like someSetting := "some value" or someTask := specialTask.value. Only definitions.

Great job @eed3si9n / @dwijnand and the rest of the sbt community :)

muuki88 commented Apr 1, 2016

I like the decision. AutoPlugins where the first step to separate the how / what things are done.
build.sbt files are nice for definitions and simple settings. Your "build-logic" can go in separate plugins.

We introduced this in our company and people where starting to actually like sbt, contributing to our company wide autoplugins, and reducing the build definitions in our projects from multipe build.sbt files and Build.scala to a single, very concise build.sbt.

A migration is straightforward. You put your logic and default settings into autoplugins (e.g. http calls to jenkins for latest versions, nexus/artifactory credentials, and so on). Then you create a build.sbt where you should only use something like someSetting := "some value" or someTask := specialTask.value. Only definitions.

Great job @eed3si9n / @dwijnand and the rest of the sbt community :)

@acjay

This comment has been minimized.

Show comment
Hide comment
@acjay

acjay Apr 3, 2016

I really feel this is the wrong direction. How is it that Scala, in its pure form, is apparently well suited to do everything, aside from describing its own builds? The .sbt layer is too clever by half, and it's a shame to see the team doubling down on it. I don't think I'm being hyperbolic by saying that this is the sort of thing that propagates the reputation of the language and ecosystem not being accessible.

Imagine you've been really sold on the benefits of Scala, and you want to use it on a new service you're writing. SBT is more or less mandatory to anybody starting a serious Scala project, and it's really difficult to avoid immediately being confronted by a whole new world of unfamiliar concepts and meta-level thinking. It's super awkward, because you have to simultaneously comprehend your build on the Scala value level, the Scala type level, and the SBT mutable engine level. The fact that you have to learn .sbt and how it differs from a regular .scala file is an additional speed bump in this process, and I would not underestimate how intimidating that is to a beginner.

As a genuine question, what's the core problem that .sbt solves? As far as I can see, the answer is that the alternative would be a comma-separated list of project settings, with an inability to define variables and methods inline. Perhaps I'm missing something there. But if that's the case, then I think the issue is ultimately that we're trying to avoid plain old Scala value-level mutability by modeling it in an SBT meta-language. I get that the result of this is an ability to introspect the build in interesting ways, but could the same thing not be accomplished by making Setting mutable and but giving it the logic to remember its own changes?

I hope the maintainers don't take this the wrong way, because it is meant as constructive criticisms, but what I'm describing here is a microcosm of the challenges the Scala ecosystem faces. The core projects are largely written by experts, and I think sometimes it's difficult for experts to look at their own constructs through the eyes of a non-expert. There many parts of the ecosystem where this is less necessary, but I would argue that as central as SBT is, this is a place where that principle should really be applied.

acjay commented Apr 3, 2016

I really feel this is the wrong direction. How is it that Scala, in its pure form, is apparently well suited to do everything, aside from describing its own builds? The .sbt layer is too clever by half, and it's a shame to see the team doubling down on it. I don't think I'm being hyperbolic by saying that this is the sort of thing that propagates the reputation of the language and ecosystem not being accessible.

Imagine you've been really sold on the benefits of Scala, and you want to use it on a new service you're writing. SBT is more or less mandatory to anybody starting a serious Scala project, and it's really difficult to avoid immediately being confronted by a whole new world of unfamiliar concepts and meta-level thinking. It's super awkward, because you have to simultaneously comprehend your build on the Scala value level, the Scala type level, and the SBT mutable engine level. The fact that you have to learn .sbt and how it differs from a regular .scala file is an additional speed bump in this process, and I would not underestimate how intimidating that is to a beginner.

As a genuine question, what's the core problem that .sbt solves? As far as I can see, the answer is that the alternative would be a comma-separated list of project settings, with an inability to define variables and methods inline. Perhaps I'm missing something there. But if that's the case, then I think the issue is ultimately that we're trying to avoid plain old Scala value-level mutability by modeling it in an SBT meta-language. I get that the result of this is an ability to introspect the build in interesting ways, but could the same thing not be accomplished by making Setting mutable and but giving it the logic to remember its own changes?

I hope the maintainers don't take this the wrong way, because it is meant as constructive criticisms, but what I'm describing here is a microcosm of the challenges the Scala ecosystem faces. The core projects are largely written by experts, and I think sometimes it's difficult for experts to look at their own constructs through the eyes of a non-expert. There many parts of the ecosystem where this is less necessary, but I would argue that as central as SBT is, this is a place where that principle should really be applied.

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Apr 3, 2016

Member

@acjay Thanks for writing this.

The core projects are largely written by experts, and I think sometimes it's difficult for experts to look at their own constructs through the eyes of a non-expert. There many parts of the ecosystem where this is less necessary, but I would argue that as central as SBT is, this is a place where that principle should really be applied.

We are in agreement on this point. The recent history of sbt, especially during sbt 0.13, has been largely driven by making the shock of sbt 0.10 more palatable through auto plugins, := macros, and improving parsing (removing blank lines). Also note that sizable portion of sbt user are Java developers (mainly via Play Java). I don't have hard evidence, but anecdotally sbt 0.13 changes have significantly improved the learning curve and getting-started problems of sbt. This is not to say that there is no learning involved with sbt.

SBT is more or less mandatory to anybody starting a serious Scala project, and it's really difficult to avoid immediately being confronted by a whole new world of unfamiliar concepts and meta-level thinking.

Once someone starts writing their build definition, they need to face the fact that build DSL is not Scala, and learn it as a separate thing, like regex or CSS. Tasks are dependency graph of calculations that gets executed in parallel. The earlier we can convey that build DSL is not Scala (but it can call Scala, similar to Scala is not Java), the more we can avoid the confusion of why := is needed.

The fact that you have to learn .sbt and how it differs from a regular .scala file is an additional speed bump in this process, and I would not underestimate how intimidating that is to a beginner.

Like snowboarding, the first day is going to suck, and the second day it gets better. I don't think you have to comprehend all the inner workings of sbt on day 1, and one should be able to get started on build.sbt by copy-pasting. I also don't think changing the file extension from .sbt to .scala is going make this problem any better.

As a genuine question, what's the core problem that .sbt solves?

It's a shorter form of writing the build DSL. Take a look at the following project/assembly.sbt:

addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.2")

It's shorter because it automatically imports the necessary names and implicits, and auto plugin also allows the plugin authors to introduce custom names and settings into the build. This is more copy-pastable than project/project/Build.scala equivalent you'd have to write if we get rid of .sbt.

People often poke fun about "simple" part of sbt (Insert simple != easy). We have a redundant functionality called build.sbt and project/Build.scala, and we are trying to get rid of one to reduce the cognitive load.

The .sbt layer is too clever by half, and it's a shame to see the team doubling down on it.

As commented above, the removal of Build.scala is as much about Project(..., settings = ) constructor. Since this was the way to define a subproject at the time project/Build.scala came out, the overlap of project/Build.scala and Project(..., settings = ) constructor usage is high. I'm going to remove Project(..., settings = ) constructor soon, so that'll require those users to change the build file anyway.

There are plugins that depend on the other plugins. When this happens the setting sequences must be loaded in some specific order, otherwise the plugins would break. From a build user who just wants to compile CoffeeScript how the plugins are related is an incidental complexity. Auto plugins solve this by the build users naming the plugins, and sbt ordering the settings based on the plugin dependencies.

Member

eed3si9n commented Apr 3, 2016

@acjay Thanks for writing this.

The core projects are largely written by experts, and I think sometimes it's difficult for experts to look at their own constructs through the eyes of a non-expert. There many parts of the ecosystem where this is less necessary, but I would argue that as central as SBT is, this is a place where that principle should really be applied.

We are in agreement on this point. The recent history of sbt, especially during sbt 0.13, has been largely driven by making the shock of sbt 0.10 more palatable through auto plugins, := macros, and improving parsing (removing blank lines). Also note that sizable portion of sbt user are Java developers (mainly via Play Java). I don't have hard evidence, but anecdotally sbt 0.13 changes have significantly improved the learning curve and getting-started problems of sbt. This is not to say that there is no learning involved with sbt.

SBT is more or less mandatory to anybody starting a serious Scala project, and it's really difficult to avoid immediately being confronted by a whole new world of unfamiliar concepts and meta-level thinking.

Once someone starts writing their build definition, they need to face the fact that build DSL is not Scala, and learn it as a separate thing, like regex or CSS. Tasks are dependency graph of calculations that gets executed in parallel. The earlier we can convey that build DSL is not Scala (but it can call Scala, similar to Scala is not Java), the more we can avoid the confusion of why := is needed.

The fact that you have to learn .sbt and how it differs from a regular .scala file is an additional speed bump in this process, and I would not underestimate how intimidating that is to a beginner.

Like snowboarding, the first day is going to suck, and the second day it gets better. I don't think you have to comprehend all the inner workings of sbt on day 1, and one should be able to get started on build.sbt by copy-pasting. I also don't think changing the file extension from .sbt to .scala is going make this problem any better.

As a genuine question, what's the core problem that .sbt solves?

It's a shorter form of writing the build DSL. Take a look at the following project/assembly.sbt:

addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.2")

It's shorter because it automatically imports the necessary names and implicits, and auto plugin also allows the plugin authors to introduce custom names and settings into the build. This is more copy-pastable than project/project/Build.scala equivalent you'd have to write if we get rid of .sbt.

People often poke fun about "simple" part of sbt (Insert simple != easy). We have a redundant functionality called build.sbt and project/Build.scala, and we are trying to get rid of one to reduce the cognitive load.

The .sbt layer is too clever by half, and it's a shame to see the team doubling down on it.

As commented above, the removal of Build.scala is as much about Project(..., settings = ) constructor. Since this was the way to define a subproject at the time project/Build.scala came out, the overlap of project/Build.scala and Project(..., settings = ) constructor usage is high. I'm going to remove Project(..., settings = ) constructor soon, so that'll require those users to change the build file anyway.

There are plugins that depend on the other plugins. When this happens the setting sequences must be loaded in some specific order, otherwise the plugins would break. From a build user who just wants to compile CoffeeScript how the plugins are related is an incidental complexity. Auto plugins solve this by the build users naming the plugins, and sbt ordering the settings based on the plugin dependencies.

@fommil

This comment has been minimized.

Show comment
Hide comment
@fommil

fommil Apr 3, 2016

I don't understand how removing .scala support removes Project(..., settings = ). Surely that is still possible from a .sbt file and if you remove the ability to provide the settings in a Project constructor, doesn't that allow us to continue to use .scala?

I challenge your claim that .scala files have more use of the settings constructor. When I made an aggressive change to ensime-sbt which broke if anybody used the settings constructor, almost everybody was doing it with .sbt files.

The only way to fix rogue usages of Project(..., settings = ) is to make that constructor private.

fommil commented Apr 3, 2016

I don't understand how removing .scala support removes Project(..., settings = ). Surely that is still possible from a .sbt file and if you remove the ability to provide the settings in a Project constructor, doesn't that allow us to continue to use .scala?

I challenge your claim that .scala files have more use of the settings constructor. When I made an aggressive change to ensime-sbt which broke if anybody used the settings constructor, almost everybody was doing it with .sbt files.

The only way to fix rogue usages of Project(..., settings = ) is to make that constructor private.

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Apr 6, 2016

Member

@fommil I forgot to mention the obvious issue with sbt.Build: override lazy val settings = .... Here's a live example of the mess - xerial/sbt-sonatype#28
Neither plugin author nor the build user can be blamed for falling into this trap.

Member

eed3si9n commented Apr 6, 2016

@fommil I forgot to mention the obvious issue with sbt.Build: override lazy val settings = .... Here's a live example of the mess - xerial/sbt-sonatype#28
Neither plugin author nor the build user can be blamed for falling into this trap.

@ralph-tice

This comment has been minimized.

Show comment
Hide comment
@ralph-tice

ralph-tice Apr 6, 2016

Nobody likes to see "their" feature or code path deprecated, and I personally am a big fan and proponent of Build.scala. But strictly from a maintainability standpoint, I don't think any open source project has the bandwidth to cater to a minority of users, nor should they. So I tried to find some sort of proxy for usage metrics, and the results (below) surprised me:

I think these searches are representative in that they count roughly similar things, and the data surprised me. I probably would not be using Build.scala today if there were some usage metrics available to help me choose what the community has de-facto voted for, and for me the schism between Build.scala and build.sbt is more confusing than it would have been to learn the build DSL in the first place.

It might be worthwhile to consider a sbt survey task to allow users to voluntarily report their feature usage metrics.

Nobody likes to see "their" feature or code path deprecated, and I personally am a big fan and proponent of Build.scala. But strictly from a maintainability standpoint, I don't think any open source project has the bandwidth to cater to a minority of users, nor should they. So I tried to find some sort of proxy for usage metrics, and the results (below) surprised me:

I think these searches are representative in that they count roughly similar things, and the data surprised me. I probably would not be using Build.scala today if there were some usage metrics available to help me choose what the community has de-facto voted for, and for me the schism between Build.scala and build.sbt is more confusing than it would have been to learn the build DSL in the first place.

It might be worthwhile to consider a sbt survey task to allow users to voluntarily report their feature usage metrics.

@DavidPerezIngeniero

This comment has been minimized.

Show comment
Hide comment
@DavidPerezIngeniero

DavidPerezIngeniero Apr 12, 2016

I'm not using Build.scala anymore

I'm not using Build.scala anymore

ches added a commit to ches/giter8 that referenced this pull request Apr 12, 2016

Update sbt, stop using `Project(..., settings = )`
A small step toward sbt 1.0 readiness. See:

    sbt/sbt#2524

@ches ches referenced this pull request in foundweekends/giter8 Apr 12, 2016

Merged

Stop using sbt Project constructor antipattern #183

@japgolly

This comment has been minimized.

Show comment
Hide comment
@japgolly

japgolly Apr 24, 2016

Contributor

For others concerned about this like I was, this is much less of a deal than I thought it was going to be.

If you haven't seen this PR for Scala.JS I suggest you take a look. You basically just turn build.sbt into an easy-to-read table of contents, rest of build stays the same.

Contributor

japgolly commented Apr 24, 2016

For others concerned about this like I was, this is much less of a deal than I thought it was going to be.

If you haven't seen this PR for Scala.JS I suggest you take a look. You basically just turn build.sbt into an easy-to-read table of contents, rest of build stays the same.

giabao added a commit to giabao/scalac-scoverage-plugin that referenced this pull request Apr 27, 2016

migrate to build.sbt & update some libraries:
+ see sbt/sbt#2524
+ use sbt-sonatype plugin
+ update scalastyle-sbt-plugin 0.8.0, sbt-pgp 1.0.0
+ update scala 2.11.8, mokito 1.10.19, scalatest 2.2.6, joda-time 2.9.3, joda-convert 1.8.1, scala-xml 1.0.5
+ remove build setting `javacOptions`. We have no .java files
+ remove Scoverage's `lazy val LocalTest = config("local") extend Test`

@eed3si9n eed3si9n modified the milestones: 1.0.0, 1.0 May 13, 2016

@t-hiroyoshi t-hiroyoshi referenced this pull request in scala-native/scala-native May 17, 2016

Closed

Move away from git submodules! #92

@DerLump DerLump referenced this pull request in lastland/scala-forklift Jul 26, 2016

Closed

"build.scala" is deprecated #19

@dwijnand dwijnand referenced this pull request Sep 6, 2016

Merged

Deprecate the Build trait #2530

@eed3si9n eed3si9n referenced this pull request Sep 6, 2016

Closed

[sbt 1.0] Forward port 0.13 changes #2352

7 of 7 tasks complete

@pdalpra pdalpra referenced this pull request in gatling/gatling Oct 31, 2016

Closed

Upgrade sbt 0.13.13 #3173

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment