These are chat archives for sbt/sbt

27th
Sep 2016
Alexander Ray
@AlexanderRay
Sep 27 2016 07:58
hey, we have created an activator project which provides a seed for play + scala + scalajs + orientdb (https://www.lightbend.com/activator/template/play-scalajs-orientdb-seed). it works fine from activator console. but if we starts it within activator ui, than it doesn't see play main class and try to start a scalajs subproject.
what would be the right sbt configuration for it?
Charles
@Checkroth
Sep 27 2016 09:04
Hi, I'm trying to trigger a task after test using dependsOn, does anybody know a way to reliably get this to run after testOnly as well?
I have something like this as a test
val t = taskKey[Unit]("Run on tests")
t := {
  println("Why u no work")
  val s: TaskStreams = streams.value
  s.log.success("Running!")
}
t <<= t triggeredBy (test in Test)
but t triggeredBy (testOnly in Test) won't work, and t triggeredBy(testOnly in Test).toTask("*") will compile, but won't actually execute on any testOnly runs
Miles Sabin
@milessabin
Sep 27 2016 14:33

It seems my expectation that,

scalaVersion in ThisBuild := "2.11.8-bin-blah"

in a local.sbt would override,

scalaVersion := "2.11.8"

at project level in build.sbt was wrong.
Is there any way of getting that overriding effect? @dwijnand?

Dale Wijnand
@dwijnand
Sep 27 2016 15:04
@milessabin no, ThisBuild is just less specific than a specific project. So to override you need to specify the project.
Or we need to think of another way, but I expect what you tried not to work
BennyHill
@BennyHill
Sep 27 2016 15:13
As a command line, this works sbt 'set every scalaVersion := "2.12.0-M5"' shell
Dale Wijnand
@dwijnand
Sep 27 2016 15:15
yeah indeed
Miles Sabin
@milessabin
Sep 27 2016 15:16
Or ++2.11.8-bin-blah.
Unfortunately it seems that for TLS "update" releases (ie. ones which don't exactly coincide with a LBS release) the changes needed to an existing project are a bit more invasive than I'd anticipated. Not terrible, but still more than I'd like: milessabin/shapeless@1ebf7b7
Of that, the only bit which can be split out to local.sbt is the scalaOrganization setting.
I think I'd expected the fullBaseScalaVersion mapping to happen automatically :-(
But at least it works uniformly across versions.
Suggestions for improvements would be very welcome.
Dale Wijnand
@dwijnand
Sep 27 2016 15:26
I would expect the cross CrossVersion.full to happen automatically
But not the fullBaseScalaVersion
@milessabin I'm not sure if this is a good idea, but what about using scalaOrganization.value % "scala-compiler" % scalaVersion.value?
Miles Sabin
@milessabin
Sep 27 2016 15:28
With the -bin suffixed version you see there cross CrossVersion.full preserves the suffix which means that the artefacts don't resolve ... is that what you'd expect?
Dale Wijnand
@dwijnand
Sep 27 2016 15:28
No I'm saying I would think it would be reasonable for cross CrossVersion.full to also consider the bin-compat rules
.. and at the same time not surprised if it currently didn't
BennyHill
@BennyHill
Sep 27 2016 15:29
@milessabin Did you see my comment on milessabin/shapeless@1ebf7b7?
Miles Sabin
@milessabin
Sep 27 2016 15:31
@dwijnand still slightly confused, why "not the fullBaseScalaVersion"? That is cross CrossVersion.full with the bin compat rules applied.
@BennyHill I have now ... no, it shouldn't because crossScalaVersions doesn't know about scalaOrganization.
BennyHill
@BennyHill
Sep 27 2016 15:33
Just a shot in the dark ;)
Dale Wijnand
@dwijnand
Sep 27 2016 15:34
@milessabin There must be a way to specify, for example, "org.typelevel" % "scala-compiler" % "2.11.8-bin-typelevel-update-1".
If fullBaseScalaVersion happened transparently, you lose the ability to do that.
Miles Sabin
@milessabin
Sep 27 2016 15:35
Oh, I see. Sure. I meant something like ...
Changing CrossVersion.full to the equivalent of,
def full: CrossVersion = new Full(fullBaseScalaVersion)
Would you accept a PR for that?
Currently it's just the identity.
Dale Wijnand
@dwijnand
Sep 27 2016 15:38
Yeah, that's what I meant by "I would think it would be reasonable for cross CrossVersion.full to also consider the bin-compat rules"
Miles Sabin
@milessabin
Sep 27 2016 15:38
Oh, cool.
Any chance of that going in for 0.13.13 if I get it to you pronto?
Dale Wijnand
@dwijnand
Sep 27 2016 15:39
Paging @eed3si9n
¯\(ツ)
Miles Sabin
@milessabin
Sep 27 2016 15:39
What about the version override thing? It's not a huge deal, but it would be nice.
BennyHill
@BennyHill
Sep 27 2016 15:40

What about the version override thing?

:+1:

Dale Wijnand
@dwijnand
Sep 27 2016 15:40
The scalaVersion in ThisBuild thing? What did you have in mind?
Miles Sabin
@milessabin
Sep 27 2016 15:41
I'm asking for suggestions :-)
If set every scalaVersion := "..." or ++... work there should be a non-interactive equivalent.
Dale Wijnand
@dwijnand
Sep 27 2016 15:42
The closest thing I can think of is @fommil's sbt/sbt#2533
Who must be in a similar "I need to change the build, without changing the build" situation
Miles Sabin
@milessabin
Sep 27 2016 15:43
Could we add a scalaVersionBinarySuffix setting which defaults to ""?
Dale Wijnand
@dwijnand
Sep 27 2016 15:44
Say it's already there, how does that help you?
Miles Sabin
@milessabin
Sep 27 2016 15:46

I could have,

scalaOrganization in ThisBuild := "org.typelevel"
scalaVersionBinarySuffix in ThisBuild := "-bin-typelevel-update-1"

In local.sbt and I wouldn't need to touch the main build.

Does that make sense?
Dale Wijnand
@dwijnand
Sep 27 2016 15:47
only if all projects are using the same scalaVersion
So if every project that used the same scalaVersion set their scalaVersion using scalaVersion in ThisBuild you wouldn't have a problem.
Miles Sabin
@milessabin
Sep 27 2016 15:48
Sure, but it's rare for subprojects to have different scala versions. I think it would be reasonable for those sorts of builds to need more manual attention.
Right.
That's not commonly done though, is it?
BennyHill
@BennyHill
Sep 27 2016 15:49

scalaVersionBinarySuffix in ThisBuild := "-bin-typelevel-update-1"

would set the value for 2.10.6, 2.11.8 and 2.12.0-RC1 surely?

Dale Wijnand
@dwijnand
Sep 27 2016 15:50
Yeah, a scalaVersionBinarySuffix would have interesting interplay with crossScalaVersions
which already has an interest story-line with sbt proper and sbt-doge
Miles Sabin
@milessabin
Sep 27 2016 15:52
I think the issue with cross versioning is related but somewhat orthogonal. There's always a chance that some dependency of some element of a cross build might be missing, cp. scoverage.
So the same could be true of a binary version suffixed compiler build. Or an alternative scala organization build for that matter.
BennyHill
@BennyHill
Sep 27 2016 15:54
scala organization build I think you would want "in ThisBuild" but scalaVersionBinarySuffix you probably want something like in AllProjects
Miles Sabin
@milessabin
Sep 27 2016 15:55
Does AllProjects exist?
BennyHill
@BennyHill
Sep 27 2016 15:55
Nope . I just invented it.
Miles Sabin
@milessabin
Sep 27 2016 15:55
How would it differ from ThisBuild?
Dale Wijnand
@dwijnand
Sep 27 2016 15:55
@milessabin there might be many such cases, scalaOrganisation is quite unused
BennyHill
@BennyHill
Sep 27 2016 15:55
ThisBuild works over all the ++scala versions
Miles Sabin
@milessabin
Sep 27 2016 15:56
@dwijnand I don't follow.
BennyHill
@BennyHill
Sep 27 2016 15:56
so it's useful, for example, for a release versions that you want all scala builds to use
Dale Wijnand
@dwijnand
Sep 27 2016 15:57
@milessabin Just saying there might be many things that don't work exactly right when trying to use scalaOrganization and a binary compatible scala version.
Miles Sabin
@milessabin
Sep 27 2016 15:57
Yes, agreed. I'm saying that a version suffix would be just the same.
No better, no worse.
How is the -bin suffix supposed to work?
I guess other users of it haven't needed to work with CrossVersion.full dependencies?
Dale Wijnand
@dwijnand
Sep 27 2016 15:59
From what I understand it's meant to be a special suffix that is taken into consideration when taking into account scala binay version.
I think you're the only user.
But again, I believe CrossVersion.full should take it into account.
Miles Sabin
@milessabin
Sep 27 2016 16:00
It was added before I got interested ... someone must have wanted it for something ;-)
Dale Wijnand
@dwijnand
Sep 27 2016 16:00
yeah, either for temporary scala release or for scala virtualized
Miles Sabin
@milessabin
Sep 27 2016 16:00
OK, I'll send that PR later today.
Right, I guess Scala virtualized probably wouldn't have had compiler plugin dependencies?
Dale Wijnand
@dwijnand
Sep 27 2016 16:02
sbt/sbt#1573
Miles Sabin
@milessabin
Sep 27 2016 16:06
So that's explicitly not handling full versioned dependencies. No point arguing whether that's a bug or a missing feature.
Dale Wijnand
@dwijnand
Sep 27 2016 16:08
I'd say implicitly not also handling. I'd still argue it should (feature or bug, the dilemma continues)
Miles Sabin
@milessabin
Sep 27 2016 16:10
Is there actually a dilemma here?
OK, dog needs a walk.
I'll PR when I get back and we can discuss there :-)
Perry
@pfn
Sep 27 2016 16:15
I wonder if my problem with running sbt console on windows (scala 2.11.7+) is some sort of jline abi problem
Dale Wijnand
@dwijnand
Sep 27 2016 16:21
Oh it's just been on my mind recently that it's always a debating point if something is a feature or a bugfix. Eg. Maven 3.2 added a feature that sbt didn't support - is that a bug or a feature? sbt/sbt#1431
Perry
@pfn
Sep 27 2016 16:25
scala> classOf[scala.tools.nsc.interpreter.jline.JLineHistory.JLineFileHistory]
res0: Class[tools.nsc.interpreter.jline.JLineHistory.JLineFileHistory] = class scala.tools.nsc.interpreter.jline.JLineHistory$JLineFileHistory
hmm, works fine in scala repl, fails in sbt repl
most definitely a jline bincompat issue :-(
Dan Di Spaltro
@dispalt
Sep 27 2016 16:33
im trying to narrow down an issue with an sbt plugin and some dependency issues, any good ideas how I go about debugging it, I have a very simple project that shows the issue
Derek Wickern
@dwickern
Sep 27 2016 16:36
@ddispaltro most likely you depend on 2 incompatible versions of commons-compress
you can use https://github.com/jrudolph/sbt-dependency-graph to see how it gets pulled in
by default SBT will pull in the latest version. you can use conflictManager := ConflictManager.strict to get an error instead
I’ve used both dependencyTree and reload plugins then dependencyTree
I just don’t see the issue =/
@dwickern ^
Perry
@pfn
Sep 27 2016 16:47
file a bug on sbt-web with that dependency tree and error
Derek Wickern
@dwickern
Sep 27 2016 16:48
you depend on commons-compress 1.6 and 1.9
Dan Di Spaltro
@dispalt
Sep 27 2016 16:48
I just can’t see where
@pfn I understand the error I just don’t really know how to get around it. Basically 1.9 implements closeable 1.6 <= does not, I just don’t know why adding the scalajs plugin would mess with it, since nothing shows me that sjs brings anything in related to compress
if I comment out the sjs plugin, the error goes away
Derek Wickern
@dwickern
Sep 27 2016 16:57
if you just enable scalajs, dependency-graph doesn't show any dependencies at all
scalajs does pull in commons-compress 1.6, i just don't know exactly where
Perry
@pfn
Sep 27 2016 16:59
odd that dependencyTree on sjs fails
Dan Di Spaltro
@dispalt
Sep 27 2016 17:00
the only thing I found was using
> reload plugins> provided:dependencyTree
Perry
@pfn
Sep 27 2016 17:00
oh, it's probably because sjs plugin embeds everything in a fat-jar
and so, you have commons-compress in a fat-jar, and then commons-compress 1.9
Derek Wickern
@dwickern
Sep 27 2016 17:01
you might be ok excluding commons-compress 1.9
especially if you don't use webjars
but i would still open a bug report in both projects
Dan Di Spaltro
@dispalt
Sep 27 2016 17:04
well I wanted to use webjars
Perry
@pfn
Sep 27 2016 17:05
rather, I assume sbt-scalajs and/or scala-js-envs are fat-jars
if they shipped fat-jars, they should have shaded...
Dan Di Spaltro
@dispalt
Sep 27 2016 17:06
I seriously don’t think they did
I was asking @gzmo about it
Dan Di Spaltro
@dispalt
Sep 27 2016 17:17
ill figure it out eventually, thanks for the help!
Channing Walton
@channingwalton
Sep 27 2016 19:56
Hi. Within sbt I would like to fork several apps (runMain). Any idea how to go about it?
eugene yokota
@eed3si9n
Sep 27 2016 21:10
@channingwalton check out https://github.com/spray/sbt-revolver first, and see their source, I guess
Shane Delmore
@ShaneDelmore
Sep 27 2016 22:33
I have a multiProject build. Is there a way to enablePlugins(BuildInfoPlugin) for all projects in my build at once or do I need to copy it into each project in the build?
Channing Walton
@channingwalton
Sep 27 2016 22:43
thanks @eed3si9n