These are chat archives for sbt/sbt

21st
Jun 2017
Sukant Hajra
@shajra
Jun 21 01:13
Is there a good SBT API for comparing versions scalaVersion, which is just a String?
CrossVersion, I see it now.
Sukant Hajra
@shajra
Jun 21 03:45
So I tried to change a setting based on scalaVersion.value, and was crossing my fingers that this would work with cross-compiling, but that didn't work. I feel when the +/++ commands are run, the settings don't get re-evaluated.
Sam Halliday
@fommil
Jun 21 07:16
@jvican I mean a brute force recompile the world flag, I'm sure I seen it somewhere.
Dale Wijnand
@dwijnand
Jun 21 09:25
that's the out the box behaviour
if you don't opt-out it comes with a big annoying message telling you exactly everything it's undone because you're a (dirty) macro user.
@shajra yeah +/++ create session settings, that are used to re-evaluate and re-define all the setting values. If you can share what you're seeing we might be able to help you out.
And your sbt-doge question, did you mean in your project or are you talking about whether sbt-doge should be changed?
Sam Halliday
@fommil
Jun 21 09:58
@dwijnand hmm, maybe it's broken for scala.meta
or, rather, doesn't support scala.meta
I was making changes to the freestyle @free macro, and nothing downstream was getting recompiled
I'd have been happy with everything being marked dirty
Dale Wijnand
@dwijnand
Jun 21 09:59
mmm could be
Sukant Hajra
@shajra
Jun 21 14:37
@dwijnand no, I mean enabling it for all projects internally. It seems to work fine.
Dale Wijnand
@dwijnand
Jun 21 14:37
yeah it's fine
Dale Wijnand
@dwijnand
Jun 21 14:52
:+1:
Jose C
@jmcardon
Jun 21 14:52
As we spoke I opened the gates to discussion on this hopefully reasonably
I sincerely believe this would lead to a positive change long term
less docs to maintain
and more convergence from the entire community
Dale Wijnand
@dwijnand
Jun 21 14:54
You propose deprecating a style that I don't see too common in the (OSS) wild, so provided we cater for those that are using that style (deprecation warnings, opt-in/opt-out, auto-rewrite) I think it's very achievable.
Jose C
@jmcardon
Jun 21 14:55
I do believe play framework is using the recursive sbt in folders style as an example
Jorge
@jvican
Jun 21 14:56
@jmcardon I don't understand what you're proposing
hasn't Build.scala disappeared in sbt 1.0?
Jose C
@jmcardon
Jun 21 14:56
@jvican removing recursive build.sbt definitions
wherein you have to recurse into folders
Jorge
@jvican
Jun 21 14:57
No way, that's impossible
First, that's not a different style, it's a feature
Second, that's the foundation for the way plugins work
Jose C
@jmcardon
Jun 21 14:58
I mean... different build.sbt files in different folders
not so much the plugins
Jorge
@jvican
Jun 21 14:58
Ah, so then I wouldn't call it recursive build definition
Jose C
@jmcardon
Jun 21 14:58
my bad on the wording then
This is partly what causes a rift so hard when having any discussions as to how to do things in sbt. Essentially supporting many different ways of doing the same thing
Jorge
@jvican
Jun 21 14:59
No worries, that was a misunderstanding
So I think that's very contentious, because what do you do with multiple .sbt files in a directory?
Dale Wijnand
@dwijnand
Jun 21 14:59
You keep those, imo.
Being able to define a gitignored local.sbt is useful.
Jorge
@jvican
Jun 21 15:00
Yes, you have to... every build in the wild uses differnt sbt files in project
Dale Wijnand
@dwijnand
Jun 21 15:00
yeah that too
Jose C
@jmcardon
Jun 21 15:00
I think different .sbt files in a top level project is fine. Not so much in different ones in many different directories adding to the hackery that needs to be done for that to work
eugene yokota
@eed3si9n
Jun 21 15:00
I'd love to see this topic captured as a GitHub issue
Jose C
@jmcardon
Jun 21 15:01
I thought it was a tad broad for an issue
Jorge
@jvican
Jun 21 15:01
I think Scala Contributors is fine for this
It will get more outreach
Jose C
@jmcardon
Jun 21 15:01
I opted for discussion first so the community could think about what exactly constitutes an issue in this
eugene yokota
@eed3si9n
Jun 21 15:01
I am guessing that the original idea was that each subdir could exist as a build on its own
but it quickly breaks down with plugins
Jorge
@jvican
Jun 21 15:01
@jmcardon so the hackery that needs to be done for that to work won't disappear because it's required for recursive builds to work
Dale Wijnand
@dwijnand
Jun 21 15:01
and build.properties
Jorge
@jvican
Jun 21 15:02
but i agree with the sentiment of removing multiple sbt files in recursive dirs that are not project
Dale Wijnand
@dwijnand
Jun 21 15:02
also at the beginning of sbt files you couldn't define projects in them, so you couldn't have single top-level build.sbt style
Jose C
@jmcardon
Jun 21 15:02
I don't mean the actual procedure in the tool, just the style
This topic is rather broad so excuse my difficulty in nailing the wording just right
Jorge
@jvican
Jun 21 15:03
Don't worry, it's fine :) We're getting somewhere
Jose C
@jmcardon
Jun 21 15:04
Mostly I think the gains of this would be lowering the barrier of entry into sbt in general
I think beginners to sbt are quite flooded with all that there is to the tool on top of the fact that looking @ different projects doesn't help because their definitions can be so wildly different
Jorge
@jvican
Jun 21 15:06
Yes, I agree on the last point
I don't see any technical difficulty in doing so
I will comment on the Scala Contributors thread later on :)
Jose C
@jmcardon
Jun 21 15:06
Converging on one style lowers this, gives opportunity for more docs on a specific style and converges, with time, maintained projects into one way wherein it's easy to pick up where someone else left off
Jorge
@jvican
Jun 21 15:06
Gitter is not the great medium to discuss this, lots of people are missing out :P
Jose C
@jmcardon
Jun 21 15:07
Oh definitely, I just wanted to give some background on gitter for the ones already here :P
Jorge
@jvican
Jun 21 15:07
thanks :)
Jose C
@jmcardon
Jun 21 15:07
I'll come back to the discussion when it's developed a bit more
No problem
Sukant Hajra
@shajra
Jun 21 18:06
I just noticed a lot of people putting the same version they put in scalaVersion also in crossScalaVersions. But it just occurred to me that it might be convenient to have them as disjoint sets? But I can't exactly put it to words. It seems kind of annoying when building everything to have to write ; command ; + command
I think there's not a right/wrong answer... just curious if people have already thought about it.
eugene yokota
@eed3si9n
Jun 21 18:59
the logical end of that line is sbt-doge
s3ni0r
@s3ni0r
Jun 21 19:12
Hi everyone, i have a custom resolver in my build.sbt file that's not challenged when resolving dependecies :
[warn]     ::::::::::::::::::::::::::::::::::::::::::::::
[warn]     ::          UNRESOLVED DEPENDENCIES         ::
[warn]     ::::::::::::::::::::::::::::::::::::::::::::::
[warn]     :: com.spingo#op-rabbit-core_2.11;1.2.1: not found
[warn]     ::::::::::::::::::::::::::::::::::::::::::::::
[warn] 
[warn]     Note: Unresolved dependencies path:
[warn]         com.spingo:op-rabbit-core_2.11:1.2.1 (/builds/root/xxxxx/build.sbt#L115)
[warn]           +- xxxxxx-commons:xxxxxx-commons_2.11:1.0
[info] 'compiler-interface' not yet compiled for Scala 2.11.7. Compiling...
[info]   Compilation completed in 8.421 s
sbt.ResolveException: unresolved dependency: com.spingo#op-rabbit-core_2.11;1.2.1: not found
    at sbt.IvyActions$.sbt$IvyActions$$resolve(IvyActions.scala:291)
    at sbt.IvyActions$$anonfun$updateEither$1.apply(IvyActions.scala:188)
    at sbt.IvyActions$$anonfun$updateEither$1.apply(IvyActions.scala:165)
    at sbt.IvySbt$Module$$anonfun$withModule$1.apply(Ivy.scala:155)
    at sbt.IvySbt$Module$$anonfun$withModule$1.apply(Ivy.scala:155)
    at sbt.IvySbt$$anonfun$withIvy$1.apply(Ivy.scala:132)
    at sbt.IvySbt.sbt$IvySbt$$action$1(Ivy.scala:57)
    at sbt.IvySbt$$anon$4.call(Ivy.scala:65)
    at xsbt.boot.Locks$GlobalLock.withChannel$1(Locks.scala:93)
    at xsbt.boot.Locks$GlobalLock.xsbt$boot$Locks$GlobalLock$$withChannelRetries$1(Locks.scala:78)
    at xsbt.boot.Locks$GlobalLock$$anonfun$withFileLock$1.apply(Locks.scala:97)
    at xsbt.boot.Using$.withResource(Using.scala:10)
    at xsbt.boot.Using$.apply(Using.scala:9)
    at xsbt.boot.Locks$GlobalLock.ignoringDeadlockAvoided(Locks.scala:58)
    at xsbt.boot.Locks$GlobalLock.withLock(Locks.scala:48)
    at xsbt.boot.Locks$.apply0(Locks.scala:31)
    at xsbt.boot.Locks$.apply(Locks.scala:28)
    at sbt.IvySbt.withDefaultLogger(Ivy.scala:65)
    at sbt.IvySbt.withIvy(Ivy.scala:127)
    at sbt.IvySbt.withIvy(Ivy.scala:124)
    at sbt.IvySbt$Module.withModule(Ivy.scala:155)
    at sbt.IvyActions$.updateEither(IvyActions.scala:165)
    at sbt.Classpaths$$anonfun$sbt$Classpaths$$work$1$1.apply(Defaults.scala:1369)
    at sbt.Classpaths$$anonfun$sbt$Classpaths$$work$1$1.apply(Defaults.scala:1365)
    at sbt.Classpaths$$anonfun$doWork$1$1$$anonfun$87.apply(Defaults.scala:1399)
    at sbt.Classpaths$$anonfun$doWork$1$1$$anonfun$87.apply(Defaults.scala:1397)
    at sbt.Tracked$$anonfun$lastOutput$1.apply(Tracked.scala:37)
    at sbt.Classpaths$$anonfun$doWork$1$1.apply(Defaults.scala:1402)
    at sbt.Classpaths$$anonfun$doWork$1$1.apply(Defaults.scala:1396)
    at sbt.Tracked$$anonfun$inputChanged$1.apply(Tracked.scala:60)
    at sbt.Classpaths$.cachedUpdate(Defaults.scala:1419)
    at sbt.Classpaths$$anonfun$updateTask$1.apply(Defaults.scala:1348)
    at sbt.Classpaths$$anonfun$updateTask$1.apply(Defaults.scala:1310)
    at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
    at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:40)
    at sbt.std.Transform$$anon$4.work(System.scala:63)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)
    at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
    at sbt.Execute.work(Execute.scala:235)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)
    at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:159)
    at sbt.CompletionService$$anon$2.call(CompletionService.scala:28)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
[error] (crawlerCommons/*:update) sbt.ResolveException: unresolved dependency: com.spingo#op-rabbit-core_2.11;1.2.1: not found
i can't figure out why this is happening
these are my resolvers :
resolvers ++= Seq(
      Resolver.sonatypeRepo("snapshots")
      ,Resolver.sonatypeRepo("releases")
      ,Resolver.typesafeRepo("releases")
      ,"spray repo" at "http://repo.spray.io"
      ,"SpinGo OSS" at "http://spingo-oss.s3.amazonaws.com/repositories/releases"
    )
and this what i got as warning messages that confirms the issue :
[info] Resolving com.spingo#op-rabbit-core_2.11;1.2.1 ...
[warn]     module not found: com.spingo#op-rabbit-core_2.11;1.2.1
[warn] ==== local: tried
[warn]   /root/.ivy2/local/com.spingo/op-rabbit-core_2.11/1.2.1/ivys/ivy.xml
[warn] ==== local-preloaded-ivy: tried
[warn]   /root/.sbt/preloaded/com.spingo/op-rabbit-core_2.11/1.2.1/ivys/ivy.xml
[warn] ==== local-preloaded: tried
[warn]   file:////root/.sbt/preloaded/com/spingo/op-rabbit-core_2.11/1.2.1/op-rabbit-core_2.11-1.2.1.pom
[warn] ==== public: tried
[warn]   https://repo1.maven.org/maven2/com/spingo/op-rabbit-core_2.11/1.2.1/op-rabbit-core_2.11-1.2.1.pom
Sam Halliday
@fommil
Jun 21 20:58
omg I wish for parallel scripted so much :cry:
Dale Wijnand
@dwijnand
Jun 21 21:12
sbt 1 scripted has improved, though I didn't review how.
Jorge
@jvican
Jun 21 21:13
sbt 1's scripted is parallel
and allows batch test execution
Dale Wijnand
@dwijnand
Jun 21 21:13
"Add parallel batch mode to scripted tests" sbt/sbt#3151
Jorge
@jvican
Jun 21 21:13
(one scripted instance can run several scripted tests)
Dale Wijnand
@dwijnand
Jun 21 21:13
Sam how much do you want sbt 1 to be released?
Jorge
@jvican
Jun 21 21:14
by the way folks, i have released a plugin you may be interested in: https://github.com/scalacenter/sbt-release-early
allows you to release on merge and via git tags + niceties to make releasing easier
good docs too (i hope)
Sam Halliday
@fommil
Jun 21 21:16
I've already got that all automated, thanks
the reason I don't do final release on merge is because I wouldn't put by GPG key on anything other than my personal computer
Jorge
@jvican
Jun 21 21:16
i don't use my personal GPG key
also, with drone releases should be more secure
Sam Halliday
@fommil
Jun 21 21:17
that's pretty sad that people are not putting passphrases on their GPG keys... I predict this will bite us one day
that said, it's not like anybody is checking the binaries.
Jorge
@jvican
Jun 21 21:17
have a look at that section, there i argue what it's required for a "secure" release process, where secure means "secure enough"
Sam Halliday
@fommil
Jun 21 21:17
and sonatype have basically zero security process
Jorge
@jvican
Jun 21 21:18
oh, i'm using passphrases for my CI gpg key :)
yeah, i wish there was an easier/better way for this
i've thought a lot about it, too
Sam Halliday
@fommil
Jun 21 21:19
it's not much better in other languages either... this will be the future of a high profile crack one day.
Sukant Hajra
@shajra
Jun 21 21:33
@eed3si9n when using sbt-doge, do you respecify the value for scalaVersion in crossScalaVersions?
Or is there a way of using sbt-doge that makes this practice unnecessary?
scalasolist
@scalasolist
Jun 21 21:39
What is the supposed way to pass JVM options to the sbt command?
eugene yokota
@eed3si9n
Jun 21 21:39
it depends. i think you would always want to have scalaVersion to some value so you can run tests without cross building. doge helps when you have heterogenous build with varying crossScalaVersions
Sam Halliday
@fommil
Jun 21 21:40
@scalasolist to sbt itself, use .jvmopts one line per arg, for launched processes you need to use fork := true and then use javaOptions ++= Seq(...)
eugene yokota
@eed3si9n
Jun 21 21:40
sbt commands normally inherits the jvm that sbt itself is running under
and what sam said
scalasolist
@scalasolist
Jun 21 21:41
@fommil thanks. .jvmopts is what I'm searching
Sam Halliday
@fommil
Jun 21 21:41
it even works on windows ;-)
Sukant Hajra
@shajra
Jun 21 21:42
@eed3si9n okay for the company, I have a small function that takes (mainTarget: ScalaTarget, others: ScalaTargets*) and it sets scalaVersion to just mainTarget, and crossScalaVersions to mainTarget +: others.
scalasolist
@scalasolist
Jun 21 21:45
where should I put .jvmopts?
Sam Halliday
@fommil
Jun 21 21:46
just in the root of your project
I also recommend using jenv to manage your version of java, and put a .java-version file beside the .jvmopts
eugene yokota
@eed3si9n
Jun 21 21:47
+1 on jenv
scalasolist
@scalasolist
Jun 21 21:47
eselect java-vm is sufficient for me
Sam Halliday
@fommil
Jun 21 21:48
the advantage of jenv is that it works on everybody's machine, not just yours, and you don't need to remember to change it
eugene yokota
@eed3si9n
Jun 21 21:49
i bought a laptop recently and found that Oracle no longer has JDK 7 download available
scalasolist
@scalasolist
Jun 21 21:49
I had not arrived yet to the point where my programs breaks jvm compatibility
Sam Halliday
@fommil
Jun 21 21:49
don't use Oracle proprietary crap, use OpenJDK
scalasolist
@scalasolist
Jun 21 21:55
Who is responsible for adding src/main/scala-2.11 in source directories: ensime plugin or sbt defaults?
Sam Halliday
@fommil
Jun 21 21:55
ensime plugin won't touch that
eugene yokota
@eed3si9n
Jun 21 21:56
i thought IDEs do that
Sam Halliday
@fommil
Jun 21 21:56
but I think the sbt defaults are wrong most of the time, so I customise them for my projects. e.g. that works for a normal release, but if you use a scala milestone release or somtehing it'll be a long name
oh, you mean actually creating the directory on disk?
read the output of running sbt ensimeConfig and then hang your head in shame :-P
scalasolist
@scalasolist
Jun 21 21:57
if @fommil says that ensime does not touch it, I would believe him. So I would search what sbt update added cross-versions as default
Sam Halliday
@fommil
Jun 21 21:58
do you mean in show sourceDirectories ? yeah, that's sbt
look in Defaults.scala in sbt
eugene yokota
@eed3si9n
Jun 21 21:59
sbt definately scans Scala specific directories
scalasolist
@scalasolist
Jun 21 21:59
@fommil I had read sbt ensimeConfig and become suspicions. I had checked show sourceDirectories and found, that someone add new stuff to it
Sam Halliday
@fommil
Jun 21 21:59
:-)
eugene yokota
@eed3si9n
Jun 21 21:59
but i am not sure if the question is about the setting or mkdir
it's about the setting
scalasolist
@scalasolist
Jun 21 22:00
The question is about sourceDirectories and how I could make them clean again
I'm writing my sbt config manually combining both .sbt and project/build.scala and expects no surprises from the sbt
Sam Halliday
@fommil
Jun 21 22:01
interesting, I can't see where I disable the default cross directories...
but that's definitely what I use to workaround the bug referenced in there
oh I think I allow the defaults plus these
scalasolist
@scalasolist
Jun 21 22:31
I'd read sbt release notes, there is something fishy recently added cross-building support. I'm afraid I should dive deeper to eliminate it
scalasolist
@scalasolist
Jun 21 23:23
@fommil JConsole shows that .jvmopts were ignored
Brian Topping
@briantopping
Jun 21 23:33
Hi all, does this look like anything that ought to work? this is my first time with these features:
    unmanagedResources in Compile += Def.task {
      val temp = IO.createTemporaryDirectory
      "curl --silent https://example.com/main-module/-/main-module-0.0.2.tgz" #| s"tar -xf -C$temp" !
        (unmanagedResourceDirectories in Compile) += temp
    }.taskValue
Palmer Lao
@palmerlao
Jun 21 23:38
I want to write a custom command that's similar to console but sets up spark. I know about initialCommands and cleanupCommands for console itself, but I was hoping for this to be separate. Could someone point me in the right direction?
scalasolist
@scalasolist
Jun 21 23:38
@fommil I ended with the following config
  val zeroCrossSettingsTemplate = Seq(
    unmanagedSourceDirectories := unmanagedSourceDirectories.value.filter(f => ! f.getName.startsWith("scala-")),
    managedSourceDirectories := Seq()
  )
  val zeroCrossSettings = inConfig(Compile)(zeroCrossSettingsTemplate) ++ inConfig(Test)(zeroCrossSettingsTemplate)
Brian Topping
@briantopping
Jun 21 23:54
Ah, it seems to look like this:
    unmanagedResources in Compile += Def.task {
      val temp = IO.createTemporaryDirectory
      val result = "curl --silent https://example.com/main-module/-/main-module-0.0.2.tgz" #| s"tar -xf -C$temp" !;
      temp
    }.value
scalasolist
@scalasolist
Jun 21 23:59
that looks more like managedResources