These are chat archives for sbt/sbt

3rd
Jan 2016
Sam Halliday
@fommil
Jan 03 2016 10:13
is there a way to share test utility code with all sbt-test scripted tests?
(without shipping it with the main plugin)
Sam Halliday
@fommil
Jan 03 2016 12:09
ok, I can definitely see that build.sbt common settings are loaded after my plugin, whereas Build.scala settings are loaded before my plugin. This is annoying.
it would also appear that if a plugin is loaded in project/plugins.sbt and project/overrides.sbt (testing snapshot version) then it fails to load with missing class exception
yuuup, http://www.scala-sbt.org/0.13/docs/Setting-Initialization.html says .sbt files come late in the game. Damn damn damn and blast it.
is there any way to detect if the project definition is using .sbt vs .scala mode?
InTheNow
@InTheNow
Jan 03 2016 12:13
@fommil Told you that was a good doc ;)
Sam Halliday
@fommil
Jan 03 2016 12:14
but hold on, the doc says the plugins come after the .sbt files, and that's not what I'm seeing
I have a failing sbt-test that works for the equivalent .scala project and the only difference is in the value of scalaVersionAtStartup := scalaVersion.value as detected by my AutoPlugin in its buildSettings phase.
This message was deleted
joy
which is definitely documented above as running after the .sbt files
if a build.sbt file has scalaVersion := "2.11.7" in it, does that get added to the Build.settings or to Project.settings?
I suspect the latter
InTheNow
@InTheNow
Jan 03 2016 12:18
use inThisBuild for the former
edit -> in ThisBuild :=
Sam Halliday
@fommil
Jan 03 2016 12:25
@InTheNow yup, done that, same thing
do the .sbt files have in ThisBuild added automatically?
InTheNow
@InTheNow
Jan 03 2016 12:27
AFAIK, no
Sam Halliday
@fommil
Jan 03 2016 12:28
I'm seeing another related problem...
in by plugin's buildSettings I do EnsimeKeys.compilerArgs := (scalacOptions in Compile).value,
and that picks up the right values for .scala builds, but not .sbt builds
should everything in by buildSettings be in ThisBuild := ?
I thought that was implied
maybe I should just go back to making these settings Project.settings... the buildSettings is all voodoo
InTheNow
@InTheNow
Jan 03 2016 12:31
I'm pretty sure you need an explicit in ThisBuild in .sbt files
Sam Halliday
@fommil
Jan 03 2016 12:31
oh, in .sbt files. I thought you meant in my plugiin
InTheNow
@InTheNow
Jan 03 2016 12:32
where is the source you are referring to?
just consider the "simple" tests under src/sbt-test
do I need in ThisBuild := when I am defining a setting in a plugin's buildSettings?
adding in ThisBuild to the build.sbt worked, thanks. I assumed that was the default behaviour.
InTheNow
@InTheNow
Jan 03 2016 12:39
I'm lost :) Is it working now, or is there still an open issue?
Also, why not remove override val settings... and just move the settings into root?
Sam Halliday
@fommil
Jan 03 2016 12:43
@InTheNow I hope you don't mean changing the tests so that they conveniently pass?
InTheNow
@InTheNow
Jan 03 2016 12:46
eh?
Sam Halliday
@fommil
Jan 03 2016 12:47
@InTheNow that is not relevant here
I'm trying to detect bad setups and warn the user, I think I'm starting to understand what the "correct" setups are. It involves using in ThisBuild in .sbt files. Which I would never use, but I'm sure our users do.
InTheNow
@InTheNow
Jan 03 2016 12:48
ok
Sam Halliday
@fommil
Jan 03 2016 12:50
I'm failing to detect the mismatches scala version. e.g. with if ((scalaVersion in Global).value != (scalaVersion.value)) {
this always returns false
InTheNow
@InTheNow
Jan 03 2016 12:51
Forcing in ThisBuild in .sbt files would be incorrect
Sam Halliday
@fommil
Jan 03 2016 12:52
why?
I'm more concerned about the fact that scalaVersion seems to mutate between my buildSettings projectSettings and when my command is run, for a trivial project
InTheNow
@InTheNow
Jan 03 2016 12:55
btw, I use override def globalSettings: Seq[Def.Setting[_]] = Seq( for most things you have in buildSettings
Sam Halliday
@fommil
Jan 03 2016 12:56
I'll have to capture what it was during buildSettings and assert on that.
@InTheNow oh, interesting, what does that do that mine doesn't? Does that force running earlier or later?
InTheNow
@InTheNow
Jan 03 2016 12:57
I can't recall off hand...
Sam Halliday
@fommil
Jan 03 2016 12:57
oh, I didn't realise that buildSettings get's called for every project that adds it
globalSettings is guaranteed to run exactly once.
is it possible to get a list of all scalaVersions for all projects?
that might help me detect the problem
InTheNow
@InTheNow
Jan 03 2016 13:01
> scalaVersion
Sam Halliday
@fommil
Jan 03 2016 13:01
@InTheNow programmatically
InTheNow
@InTheNow
Jan 03 2016 13:02
heh, one min
Sam Halliday
@fommil
Jan 03 2016 13:02
oh bugger it, I'm addiing a Setting to capture the value when my projectSettings are run
something is mutating the scalaVersion in Global and scalaVersion in ThisBuild
because it always agrees with the scalaVersion per project, but I can see clearly that the two projects in this test config have different versiions
InTheNow
@InTheNow
Jan 03 2016 13:08
do you still need to "list of all scalaVersions for all projects"?
Dale Wijnand
@dwijnand
Jan 03 2016 13:19
project settings vs build settings vs global settings btw: http://www.scala-sbt.org/0.13/docs/Plugins.html#projectSettings+and+buildSettings
Sam Halliday
@fommil
Jan 03 2016 13:20
@dwijnand thanks, I got that already. But there is something funky going on with scalaVersion in these scopes
@dwijnand I think I solved it by capturing scalaVersion for the root project (effectively dynamically) and comparing that to each project in turn
Dale Wijnand
@dwijnand
Jan 03 2016 13:21
what are the before and after values?
Sam Halliday
@fommil
Jan 03 2016 13:21
but it seems that the order of loading of buildSettings in Build.scala vs build.sbt is not as documented
@dwijnand in this test https://github.com/fommil/ensime-sbt/blob/fix-0.3.1-regressions/src/sbt-test/ensime-sbt/bad-build.scala/gen-ensime.expect there are two projects, but with differing scalaVersion. When my plugin runs scalaVersion in ThisBuild and scalaVersion in Global both return consistently the same values a scalaVersion (when in a project scope). Which can't be right because that means the ThisBuild and Global values are mutating!
I'm guessing there is some voodoo in sbt to workaround bad configurations
but I'm not going to workaround it, because I can't (or don't have the time to), so I need to detect when it happens and spit out a warn/error
Sam Halliday
@fommil
Jan 03 2016 13:29
so here's a minimal failing case:
scalaVersion := "2.11.7"
that's the only line in the build.sbt
then try to read scalaVersion.value in a buildSettings from an AutoPlugin. It'll come up as 2.10.5
but it is picked up as 2.11.7 when called from projectSettings
so I don't believe the ordering rules in http://www.scala-sbt.org/0.13/docs/Setting-Initialization.html
InTheNow
@InTheNow
Jan 03 2016 13:39
I suspect that 2.10.5 is just the "default"
try mkdir tmp; cd tmp; sbt scalaVersion
Sam Halliday
@fommil
Jan 03 2016 13:40
@InTheNow yes, it is, but the point is that the ordering rules are not as described
@InTheNow the setting defining 2.11.7 should be read before the AutoPlugin's buildSettings
but its not
so .sbt file loading is really not as described
InTheNow
@InTheNow
Jan 03 2016 13:44
AutoPlugin's buildSettings should be included first

The default inclusion order for sbt is:

All AutoPlugin settings
All settings defined in project/Build.scala
All settings defined in the user directory (~/.sbt/<verison>/*.sbt)
All local configurations (build.sbt)

Sam Halliday
@fommil
Jan 03 2016 13:46
@InTheNow that's not what the diagram shows
InTheNow
@InTheNow
Jan 03 2016 13:46
It does, on the right hand side
Sam Halliday
@fommil
Jan 03 2016 13:46
Compile / Order All Plugins is the last
User plugins come first
is the left the loading order and the right is the application order?
InTheNow
@InTheNow
Jan 03 2016 13:47
yep ;)
Sam Halliday
@fommil
Jan 03 2016 13:48
uuuuugh
ok, well there is still something subtle going on if the .scala and .sbt behaviours are different
InTheNow
@InTheNow
Jan 03 2016 13:48

After loading/compiling all the build definitions, sbt has a series of Seq[Setting[_]] that it must order. As shown in the diagram, the default inclusion order for sbt is:

All AutoPlugin settings
All settings defined in project/Build.scala
All settings defined in the user directory (~/.sbt/<verison>/*.sbt)
All local configurations (build.sbt)

Sam Halliday
@fommil
Jan 03 2016 13:49
I suspect that project/Build.scala might be happening before AutoPlugiins
and that is perhaps the bug in sbt
actually, the behaviour of Build.settings is not defined here. Only buildSettings
actually, that's wrong because there isn't even such a thing as buildSettings in Build
anyway, I think I have the behaviour under control now
basically only use buildSettings for static defaults, never reference anything else, and that's a good rule of thumb
because there is something subtle going on about ordering around .sbt and .scala files
InTheNow
@InTheNow
Jan 03 2016 13:54
:+1:
Josh Suereth
@jsuereth
Jan 03 2016 16:02
@fommil No, that's how it's supposed to be
Build.scala doesn't really abide by the normal things
and we can't really re-organize how it works given how it's implemented, unfortunately
Perry
@pfn
Jan 03 2016 16:05
lots of settings loading ordering is weird when you have multiple sbt file in multiple projects
I find that a lot of free standing settings get loaded before project settings and tend to disappear on me
Dale Wijnand
@dwijnand
Jan 03 2016 17:32
Yeah I've mostly seen and use a single build.sbt file