These are chat archives for sbt/sbt

1st
Dec 2016
Derek Wickern
@dwickern
Dec 01 2016 00:00
oh, wow
Andy Garbutt
@agarbutt
Dec 01 2016 00:00
is that what you are looking for?
There is also a launcher version in the same package space.
Derek Wickern
@dwickern
Dec 01 2016 00:02
it looks like it might create a separate jar for the classpath, but i'm not pickyk
using a wildcard classpath on Windows came back to bite me
Andy Garbutt
@agarbutt
Dec 01 2016 00:05
yeah, same here today...
and now i am chasing a rabbit ...
any ideas on how to inspect a version of a dependent plugin in another plugin?
Derek Wickern
@dwickern
Dec 01 2016 00:09
classOf[SomeClassInOtherPlugin].getPackage.getImplementationVersion
Andy Garbutt
@agarbutt
Dec 01 2016 00:10
hmm, ill try that
Derek Wickern
@dwickern
Dec 01 2016 00:11
then statically compile against the older version
assuming it's backwards compatible
Andy Garbutt
@agarbutt
Dec 01 2016 00:16
thanks for helping me think about this some more...
drhumlen
@drhumlen
Dec 01 2016 13:30
Is build.sbt evaluated line-by-line? How does name := "Foobar" set the name of the project without causing a side-effect? Or does that statement actually perform the side-effect of setting the name?
Paolo G. Giarrusso
@Blaisorblade
Dec 01 2016 13:31
@drhumlen SBT collects the settings together and then applies them to construct a new map of settings
drhumlen
@drhumlen
Dec 01 2016 13:31
So name := "Foobar" a pure expression (with referential transparency)?
ritschwumm
@ritschwumm
Dec 01 2016 13:31
yes
drhumlen
@drhumlen
Dec 01 2016 13:32
How does sbt collect all the settings? By evaluating each line individually?
Because, normally, the return value is only the last expression (ie in a function/method)
(...Which is the only thing visible outside)
Paolo G. Giarrusso
@Blaisorblade
Dec 01 2016 13:33
ah right, they're evaluated individually
Dale Wijnand
@dwijnand
Dec 01 2016 13:33
yes, it parses and evaluates them individually
drhumlen
@drhumlen
Dec 01 2016 13:33
Aha. That's a huge gotcha.
Paolo G. Giarrusso
@Blaisorblade
Dec 01 2016 13:33
a build definition is not anything like a function body
if you want the "real Scala" version, it's something like
lazy val commonSettings = Seq(
  organization := "com.example",
  version := "0.1.0",
  scalaVersion := "2.11.8"
)
Dale Wijnand
@dwijnand
Dec 01 2016 13:34
including doing things like separate definitions from dsl entries, so this works:
name := getName()

def getName() = "foo"
Paolo G. Giarrusso
@Blaisorblade
Dec 01 2016 13:35
@drhumlen if you care about understanding these things well, the "getting started" guide can help you: http://www.scala-sbt.org/1.0/docs/Getting-Started.html. It's a lot, yes
but it does give the proper picture
drhumlen
@drhumlen
Dec 01 2016 13:35

Cool. Another thing that puzzles me frequently:

val foobar = project in file(".")

now, the root project magically is called foobar. But in my code that's only a local variable? Does the variables you declare "leak" out, or is there some macro magic going on?

ritschwumm
@ritschwumm
Dec 01 2016 13:36
macro magic
Paolo G. Giarrusso
@Blaisorblade
Dec 01 2016 13:36
uh. There's definitely macro magic in some places (e.g. .value), I think also in project, but there I don't know the details
Dale Wijnand
@dwijnand
Dec 01 2016 13:37
yes, that project macro ensures that your val name and your project id match
so what you use at compile time in your build definition and at runtime in the sbt shell match
instead of accidentally doing something like
val foo = Project("bar", file("."))
drhumlen
@drhumlen
Dec 01 2016 13:38
Aha. I was starting to suspect that. But my mental model has always been that if you say val something = _____, then something is available inside $ sbt > ..... But I realize now that that's not what's going on at all
Paolo G. Giarrusso
@Blaisorblade
Dec 01 2016 13:41
@drhumlen have you looked at some .scala build definition?
object Build extends sbt.Build sbt.Build contains some macro magic too, right? Or otherwise, that Build.scala file wouldn't do anything?
Dale Wijnand
@dwijnand
Dec 01 2016 13:50
reflection magic, the projects defined in it are taken as the projects of the build
but the sbt.Build trait is now deprecated
drhumlen
@drhumlen
Dec 01 2016 14:43

If I put: name := "Moo" on a line, sbt picks it up.
But if I put val temp = name := "Moo" on a line, sbt does not pick it up...

But with projects, ie: val temp = Project(..........) or val temp = project in file("."), it is picked up by sbt - even though it's assigned to a local variable

And not the result of running the line
Isn't that a little inconsistent?
Does project in file(".") actually trigger the side-effect of creating the project?
Why is there a difference where val x = project matters, while val y = name := "test" does not matter?
Dale Wijnand
@dwijnand
Dec 01 2016 14:50
projects are assigned to vals so you can then use them, like for aggregate and dependsOn
while settings are just defined and picked up as expressions
drhumlen
@drhumlen
Dec 01 2016 14:53
Yea, it sounds very reasonable to do it that way because it's practical to work with. I'm just curious how it works (Sorry for all the questions, I just want to understand the internals of sbt)
val myProject = project in file(".") is not an expression (ie it doesn't "return" anything). But the project is still "registered". How?

def runMe = {val notUsed = project in file("."); name := "Moo" }
runMe

Now the project (called "notUsed") is registred (right?), even though it's never "returned"/the result of a line inside build.sbt. So there's gotta be a side-effect there, right?

Dale Wijnand
@dwijnand
Dec 01 2016 14:57
values that are of type Project are picked up as the projects of the build in build.sbt
no it won't be
jaksky
@jaksky
Dec 01 2016 15:29
Hello, I have a single project with test and integration tests. Does anybody know how do I specify sharing sources of those tests between test and integration test? The reason is that I have some mock data fixtures in test and would love to reuse those in integration tests
Erik LaBianca
@easel
Dec 01 2016 16:05
You can put the fixtures in a subModule that’s a dependency, or replace the default it:test config with one that uses the regular test sourcePath but filters based on the test name or something.
Ólafur Páll Geirsson
@olafurpg
Dec 01 2016 16:36
Hello! I am trying to create a compileSpecial task that is identical to the compile task except with one compiler plugin added to libraryDependencies. Any suggestions/tips on how I could approach this?
jaksky
@jaksky
Dec 01 2016 16:45
@easel So I suppose that I have to modify following lines
.configs(IntegrationTest) .settings(Defaults.itSettings : _*) which setting needs to be modified? Can I change only one setting
Erik LaBianca
@easel
Dec 01 2016 16:47
Something like sourceDirectories in ItTest += sourceDirectory in Test might work but your it test runner will probably pick up the unit tests under it:Tests so you will probably need to filter those out as well.
I use a filter like this: def itFilter(name: String): Boolean = name.startsWith("ittest") || name.endsWith("ITest”)
and then testOptions in ItTest := Seq(Tests.Filter(Common.itFilter) ) to apply it.
Joe Adams
@joe-adams
Dec 01 2016 17:32
Can you do an sbt task to make it wait one second before doing the next task?
Oh, wait it looks like you can. I was just looking at the wrong thing.
Joe Adams
@joe-adams
Dec 01 2016 17:52
Oh no, it won't wait
Ólafur Páll Geirsson
@olafurpg
Dec 01 2016 20:00

I managed to get a terribly hacky solutions working by using a command

val scalafix = Command.command("scalafix") { state =>
  "set libraryDependencies in ThisBuild += <my-compiler-plugin>" ::
    "; clean; compile;" ::
    "session clear" :: // might ruin some custom session :/
    state
}

I only want the compiler plugin present when compiling from the scalafix command/task. I am curious to know if someone has a better approach.