These are chat archives for sbt/sbt

23rd
Jan 2016
Sam Halliday
@fommil
Jan 23 2016 11:48
is it possible to disable the scalacheck test runner?
I run my checks with scalatest, and I don't need another runner giving me noise about no tests
Hans W. Uhlig
@huhlig
Jan 23 2016 18:29
can sbt do submodule builds like maven can? specifically referencing parameters from the parent project without compiling it?
OlegYch
@OlegYch
Jan 23 2016 18:30
what kind of parameters>
?
all submodules in sbt are defined as values in scala file, so you can do pretty much anything you can do in scala
Sam Halliday
@fommil
Jan 23 2016 18:32
@huhlig compilation will be trigged if you're depending on a Setting that is actually a Task that depends on compileTask... which is unfortunately, pretty much everything (because it is a dependency of products).
what you're requesting was implemented in sbt/sbt#2354 and will be in 0.13.10
but you need to make sure you know that that's doing. I wouldn't recommend using it until you become very experienced with sbt
OlegYch
@OlegYch
Jan 23 2016 18:35
Setting and Task are very different things...
no Setting can depend on Task
Sam Halliday
@fommil
Jan 23 2016 18:38
@OlegYch what is the common supertype of Setting and Task ?
OlegYch
@OlegYch
Jan 23 2016 18:40
is this a quiz?
Sam Halliday
@fommil
Jan 23 2016 18:41
is anybody seeing this with 0.13.10-RC1?
/home/fommil/.sbt/0.13/global.sbt:8: error: reference to useGpgAgent is ambiguous;
it is imported twice in the same scope by
import com.typesafe.sbt.pgp.PgpKeys._
and import _root_.com.typesafe.sbt.SbtPgp.autoImport._
useGpgAgent := true
is there now an implicit dependency on the pgp plugin?
Perry
@pfn
Jan 23 2016 18:46
no
@fommil it's the change to add auto imports in Global filed
it's a bit overzealous and imports both plugin and auto import
and causes that
Sam Halliday
@fommil
Jan 23 2016 18:47
this is why I hate .sbt files. .scala for the win.
Perry
@pfn
Jan 23 2016 18:48
you could do it in Scala file as well
I don't hate still, you could import manually as well
Dale Wijnand
@dwijnand
Jan 23 2016 18:50
@fommil autoImports are imported in global now
should've always, so now it does
but that's the fall out
Sam Halliday
@fommil
Jan 23 2016 18:54
ta, I think I have a workaround by not doing a wildcard import
Dale Wijnand
@dwijnand
Jan 23 2016 19:02
@fommil and the common supertype(s) of Setting and Task is Object:
scala> val t: Task[Int] = Task[Int](Info(), Pure(() => 1, true))
t: sbt.Task[Int] = Task(_)

scala> val s: Setting[Int] = Def.setting[Int](Def.ScopedKey(Scope.GlobalScope, AttributeKey[Int]("foo")), Def.value(1))
s: sbt.Setting[Int] = setting(ScopedKey(Scope(Global,Global,Global,Global),foo)) at NoPosition

scala> Seq(t, s)
res0: Seq[Object] = List(Task(_), setting(ScopedKey(Scope(Global,Global,Global,Global),foo)) at NoPosition)
OlegYch
@OlegYch
Jan 23 2016 19:03
@dwijnand do you mean if i add plugin in my project it will be autoimported in global plugins?
Sam Halliday
@fommil
Jan 23 2016 19:04
@dwijnand thanks. How come a common sig is Seq[Setting[_]] even if those things are computed from Task?
Dale Wijnand
@dwijnand
Jan 23 2016 19:04
not sure
I'm finding out these answer as you ask the questions :)
@OlegYch the plugin's autoImport's content will be imported in your ~/.sbt/0.13/*.sbt files, like they are in your build.sbt file in your project
@fommil The answer is probably in this section which I should read: http://www.scala-sbt.org/0.13/docs/DevGuide-Notes.html
OlegYch
@OlegYch
Jan 23 2016 19:12
hm what's the reason for that?
Dale Wijnand
@dwijnand
Jan 23 2016 19:15
consistency and convenience
It was never not meant to be that way.
OlegYch
@OlegYch
Jan 23 2016 19:17
how would someone use plugin specified in only one project from global config?
Perry
@pfn
Jan 23 2016 19:28
@OlegYch, you would have added the plugin globally already
OlegYch
@OlegYch
Jan 23 2016 19:30
oh so if i only add the plugin in one project it won't be imported in global?
Dale Wijnand
@dwijnand
Jan 23 2016 19:37
no no
it's about providing imports in ~/.sbt/0.13/*.sbt files for plugins added in ~/.sbt/0.13/plugins/*.sbt files
OlegYch
@OlegYch
Jan 23 2016 19:50
oh cool then
eugene yokota
@eed3si9n
Jan 23 2016 21:30
@fommil us fixing imports actually broke your import workaround.. this is interesting
eugene yokota
@eed3si9n
Jan 23 2016 21:41
I'm filing this as a regression sbt/sbt#2415
Daniel Spiewak
@djspiewak
Jan 23 2016 23:33
@eed3si9n I'm trying to do something REALLY weird. Basically, I have a project which has a subproject with a single set of sources that I want to compile twice, once with each of two different dependencies. I tried doing this by creating two subprojects pointed at the same source dir with different target dirs, and that didn't work (silently didn't compile to the second dir). I've also tried doing the same thing but by symlinking the src directory (i.e. two different subproject dirs, but one subproject sources are relatively symlinked to the other's). That also doesn't work for the same reason
Is there some sort of wonky compiler cache that's defeating me here? And if that's the case, can I turn it off?
One of teh two projects that I'm trying to do this with is here: https://github.com/djspiewak/shims
This is a previous state of the project where I tried hte first approach (i.e. same subproject dir, but configured explicitly different target dirs)