Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

Well I guess I'll have to dig deeper into pants now.

Shit you guys need to change the name of the product lol

So, basically in the project/build.sbt, you had a dependency on another build project?

which was the SuperProject you're talking about?

Wait I guess that doesn't fix the scalaVersion thing.

sure it can. set it once in the super project

I'm going to try out a few things (including having a super project with scala version 2.11 that everyone "`dependsOn`". I suspect what you're saying may have worked with `Build.scala` type builds but I don't see a way to get that working with `build.sbt` type builds which is the only type of definition allowed now.

er... you don't depend on it. you inherit from it.

i don't even know whether that is still possible with a build.sbt.

Yes so the inheritance thing is not possible anymore because `Build.scala` style definitions are dead. But maybe if I depend on a project with `scalaVersion := 2.11` then all the projects automatically get it.

mammehjammeh: i solve your problem in an sbt polyrepo with an sbt plugin that sets / factors out common boilerplate across many projects <https://github.com/hammerlab/spark-genomics>

agreed with stu below that the sbt gitter is probably a good place for help on this

Thank you for telling me this- I will check this out.  I have done something similar for polyrepo if you're interested.

Sorry I don't know how to attach fils so I will copy paste my file with duplicatish information removed

package globalbuild

import sbt._
import sbt.Def.Initialize
import sbt.Keys._
import sbt.Project.projectToRef
import org.scalajs.sbtplugin.ScalaJSPlugin.autoImport._

class GlobalBuild{
  val scalaVersion = "2.11.8"
  
  def scalacOptions = Seq(
    "-Xlint",
    "-unchecked",
    "-deprecation",
    "-feature",
    "-encoding", "utf8"
  )

  val versionLibSpecs2           = "3.0"

  def jvmAmmonite        : sbt.ModuleID = "com.lihaoyi"             %% "ammonite-ops"    % versionLibAmmonite 

  def jsScalaTest     : sbt.Def.Initialize[ sbt.ModuleID ] = Def.setting{ "org.scalatest"  %%% "scalatest"   % versionLibScalaTest  }

  def sharedScalaTags : sbt.Def.Initialize[ sbt.ModuleID ] = Def.setting{ "com.lihaoyi"    %%% "scalatags"    % versionLibScalaTags }

  object LocalProjects {
    val mono_root = System.getenv( "MONO_ROOT" )

    def monoProject( project: String )
    : RootProject = 
    {
      localProject( java.nio.file.Paths.get( mono_root , "scala", project ).toString )
    }
    
    def localProject( path: String )
    : RootProject = 
    {
      RootProject( file( path ) )
    }

    val selector = monoProject( "Selector" )
    val squery   = monoProject( "SQuery" )
  }

  val versionPluginPlay          = "2.6.0-M2"

  //Keep in sync with corresponding value in build.sbt of this project
  val versionPluginScalaJs       = "0.6.13"

  def resolverTypesafe: sbt.MavenRepository = "Typesafe repository" at "<https://repo.typesafe.com/typesafe/releases/>"

  def pluginPlay          :sbt.ModuleID = "com.typesafe.play"       % "sbt-plugin"       % versionPluginPlay 

}

Accompanying build.sbt: 
addSbtPlugin("org.scala-js" % "sbt-scalajs" % "0.6.13")

libraryDependencies += "org.scala-sbt" % "sbt" % "0.13.13"

I then depend on this project from the build project of all projects.

cool. per some comments from you (iirc) elsewhere in <#C046T6T9U|general>, i've also not found a satisfactory solution for expressing modules' dependence on one another / allowing cache-invalidation to flow properly through the task DAG in SBT; I basically have to publish to local maven repo to propagate changes, or duplicate dependency information in a slightly clumsy way, cf. <https://github.com/hammerlab/spark-genomics/blob/06c56e50b26b1fef0689fd839936ee24c62d174c/build.sbt#L14-L77>

<@U4L7D17RV> : have you considered visiting the sbt gitter room?

I've thought of this problem only now to be honest. I asked you as a spur of the moment thing whiel discussing other problems- I shouldn't have. I'm spending time figuring this out on my own and if I can't then I will go over there and ask.

<@U06A03HV1> Thank you. Something similar to you suggested worked. 3 steps: 1) Create a global settings project. 2) project/build.sbt -&gt; Make your build depend on the global settings project  3) build.sbt scalaVersion := globalSettings.scalaVersion

<@U4KCS8SQ3> ah, sorry - I think what you want if you’re on an older release of pants is `resource_targets=[’:resources’]`

(I tend to think of pants usage and such as whats in current master, heh)

<@U4L7D17RV> -- in my experience moving a project from sbt to pants, we mostly integrated command line tools as pants run targets, rather than rely on plugin support from the build tool. Now, we're finally biting the bullet and writing pants plugins. Which is both fun and fairly easy. :slightly_smiling_face:

I'm kind of a novice, though, so you might not want to listen to me.