These are chat archives for sbt/sbt

15th
Dec 2016
hbuerger
@hbuerger
Dec 15 2016 17:14
sbt kills me! How to simply execute a task at every compile? I already have the task and can call myTask at sbt prompt. And with sbt 13.13, the old stuff I found issues warnings I don't want to have.
or u are getting warning with this?
marios iliofotou
@imarios
Dec 15 2016 17:29
You might want to replace <<= with := and do something like this:
compile in Compile := { println("hello") ; (compile in Compile).value }
Ryan Williams
@ryan-williams
Dec 15 2016 20:43

geez, just lost several hours to a scalatest test not compiling in intellij but running fine from sbt on CLI… seems like i needed to nuke ~/.ivy/cache/org.scalatest to get it working again from IntelliJ. brutal.

I am now on Ivy via SBT for the first time in years and this pattern on SO – rm -rf this or that part of ~/.ivy2/cache – is disconcerting! I wonder what the right place is to file bugs? In this case I suppose it’s intellij’s scala support that was messing up, since SBT CLI was working ok.

marios iliofotou
@imarios
Dec 15 2016 21:04
@ryan-williams maybe you have conflicting libraries in your IntelliJ classpath? IntelliJ does it's own stuff. It's pretty common for dependecies to work fine on sbt but not on IntelliJ.
(obviously this is from of an IntelliJ question rather than sbt, I think)
Ryan Williams
@ryan-williams
Dec 15 2016 21:06
yea sry i can punt this to a youtrack issue… gtk that IJ causing issues like this is not unheard of; would love to help that be resolved.
marios iliofotou
@imarios
Dec 15 2016 21:08
Look for Project Structure on IntelliJ go to the project you have issues and look if there are different scalackeck libraries there, try deleting the older one (or the one you don't want) and try again
Ryan Williams
@ryan-williams
Dec 15 2016 21:13
ok cool i will try that. i just saw the issue again and deleted my whole ivy cache, slightly accidentally, so re-DL’ing the world atm
Rob Norris
@tpolecat
Dec 15 2016 21:49
So, do I have to do .enablePlugins(Woozle) individually for every sub-project in a multi-project build?
Ryan Williams
@ryan-williams
Dec 15 2016 21:53

just a small post-script to the above but it seems like IntelliJ was putting scalatest 2.2.6 on my classpath in “compile” scope due to a transdep via spark-core, even when I excluded scalatest from my spark-core dep, while my project was also depending on scalatest 3.0.0 in “test” scope, and intellij was not only not excluding 2.2.6 but the “3.0.0”%”test” one wasn’t evicting the “2.2.6”%”compile” one, so they were both on the classpath and that was causing issues.

elevating my “3.0.0” dep to “compile” scope seems to work-around it but i am going to try to get a couple things herein into file-able shape. thanks @imarios for the Project Structure pointer, that was my best signal that 2.2.6 was still working its way in, and in “Compile” scope.

Rob Norris
@tpolecat
Dec 15 2016 21:55
.enablePlugins(GitVersioning) adds things like git.useGitDescribe that I can see in my build file but not in the SBT console. How do I reference them?
OlegYch
@OlegYch
Dec 15 2016 21:59
eval git.useGitDescribe.key
Rob Norris
@tpolecat
Dec 15 2016 22:07
Well that's a new one.
> eval git.useGitDescribe.key
[info] ans: sbt.AttributeKey[Boolean] = useGitDescribe
How do I get a boolean out of it?
OlegYch
@OlegYch
Dec 15 2016 22:09
you mean a string?
show useGitDescribe
Rob Norris
@tpolecat
Dec 15 2016 22:11
So it has to be qualified in the build file but cannot be qualified at the sbt prompt.
Rob Norris
@tpolecat
Dec 15 2016 22:16
I'm confused. baseVersion here is unavailable at the prompt but versionProperty is. What determines the keys that get exposed to the repl vs the build in an auto-plugin?
> eval git.baseVersion
[info] ans: sbt.SettingKey[String] = sbt.Scoped$$anon$1@6b75c0ad
> git.baseVersion
[error] Expected ID character
[error] git usage:
...
> show baseVersion
[error] No such setting/task
...
OlegYch
@OlegYch
Dec 15 2016 22:19
maybe baseVersion is not set
try inspect
Derek Wickern
@dwickern
Dec 15 2016 22:58
i have never seen a setting qualified like that
OlegYch
@OlegYch
Dec 15 2016 23:33
like "git." ?
it's just regular scala code
everyone invents there own ways to disambiguate setting names and everyone does it poorly
strings suck
Derek Wickern
@dwickern
Dec 15 2016 23:51
yeah, i know, just from sbt point of view everything is usually in global scope (or auto imported into global scope)