These are chat archives for sbt/sbt

30th
Mar 2016
Greg Symons
@gregsymons
Mar 30 2016 00:42
Is there a way I can log inside a function that sets a SettingKey?
Perry
@pfn
Mar 30 2016 03:24
@gregsymons sLog.value
Dale Wijnand
@dwijnand
Mar 30 2016 07:30
@pfn Do you know when that's better than streams.value.log?
Man, I would have really liked if there was more consultation regarding this
I just see this potentially creating a lot of pain in the long run
Dale Wijnand
@dwijnand
Mar 30 2016 12:18
The title is not accurate and therefore miss-leading.
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:20
Not from what I can see
Dale Wijnand
@dwijnand
Mar 30 2016 12:20
you can still use *.scala files to define your build.
It's just the Build trait that's being dropped.
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:21
So how does the build get picked up?
You need to define the build for it to valid Scala iirc, also how would you refer to seperate builds?
Dale Wijnand
@dwijnand
Mar 30 2016 12:22
what do you mean?
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:23
Well in sbt/sbt#2524, you demonstrate what an equivalent .sbt version of a .scala build is, what would the new .scala version be?
Dale Wijnand
@dwijnand
Mar 30 2016 12:24
The intent is that there is just one format: the .sbt format. But you can still use .scalafiles for utilities, local auto-plugins, etc. That support is not being dropped.
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:25
Right, so my complaint still stands then
Dale Wijnand
@dwijnand
Mar 30 2016 12:25
It's my belief that people's hang-ups are due to tooling. Currently IntelliJ is the only tool that provides support for the .sbt format.
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:26
@dwijnand IntelliJ’s tooling has issues with .sbt because its .sbt and not .scala btw
Equivalent versions of .scala for .sbt work fine in IntelliJ because its actual valid scala code
Dale Wijnand
@dwijnand
Mar 30 2016 12:26
As far as I can see, most tooling still has issues with .scala.
ensime, idea, all of them.
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:27
Right, but specific to .sbt vs .scala for SBT, the point I made before stands corrected (I know this because I converted my .sbt’s to .scala for that reason)
You are actually making it harder for IDE’s to make tooling support by officially supporting some weird dialect of Scala thats not proper Scala
Dale Wijnand
@dwijnand
Mar 30 2016 12:27
Yeah, I know.
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:28
Like honestly, I don’t see how this was a technically good solution. It seems like a short term solution that will cause a lot of pain in the medium/long term
Dale Wijnand
@dwijnand
Mar 30 2016 12:29
In my experience I find working with .sbt files in IntelliJ works well.
For simple things vim is enough too.
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:29
Sure, it works well, but it reports errors that aren’t actually errors, and that is due to it being .sbt
Dale Wijnand
@dwijnand
Mar 30 2016 12:30
Do you know if the sbt support is open-source?
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:30
Like I don’t understand what you guys are solving here, if you wanted to remove a certain way of loading build definitions then the better way would have been to deprecate that function and provide a proper version
@dwijnand No idea
Dale Wijnand
@dwijnand
Mar 30 2016 12:31
What errors have you seen in .sbt?
in IntelliJ
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:31
But as it stands, supporting Scala is hard enough, you are basically asking tools to support Scala (almost) twice now
@dwijnand Loading auto plugins with enablePlugins(…) is an obvious immediate one
In my previous company where we used auto plugins a lot, its all red squiggly’s in IntelliJ
Dale Wijnand
@dwijnand
Mar 30 2016 12:33
I've used enablePlugins. Where/how does that error?
Matthew de Detrich
@mdedetrich
Mar 30 2016 12:33
Expression of type DslEntry must conform to Def.SettingsDefinition in SBT file
I believe I have already reported it
Thats by just having an enablePlugins in a fairly trivial build.sbt file
Reported them to IntelliJ guys, I mean
@dwijnand Also there are other differences which I posted in that thread
Dale Wijnand
@dwijnand
Mar 30 2016 12:41
You're right it does show red squigglies.
It's not the first time I've been surprised by that - I've been told about red squigglies in Scala files in IntelliJ before, which somehow my eyes didn't see before.
Seems I've trained my eyes to ignore some categories of errors in IntelliJ
The one I've seen before is "wrong forward reference", when it actually works.
Halvor Granskogen Bjørnstad
@halvorgb
Mar 30 2016 13:33
Using sbt-native-packager, i'm experiencing that sbt docker:stage only stages the lib folder and no binary.
I'm thinking I've done something wrong in my build.sbt file, but I'm confused.
Dale Wijnand
@dwijnand
Mar 30 2016 13:34
(just fyi, you can also try asking in https://gitter.im/sbt/sbt-native-packager)
Halvor Granskogen Bjørnstad
@halvorgb
Mar 30 2016 13:37
I'll ask there, thanks.
Perry
@pfn
Mar 30 2016 14:20
@dwijnand, streams isn't available from setting
so always :p
Erik LaBianca
@easel
Mar 30 2016 15:16
FWIW I have a very large multi-project build with a bunch of sbt plugins, auto-plugins, and what have you and the intellij support in my build.sbt seems to be more or less spot on. I personally like the split — I put “code” in my project/Stuff.scala files and just do really basic stuff like lazy val project = project.in(“.”) type stuff in build.sbt. I’d be just as happy if the .sbt were a yaml file or some other standard syntax though, no need for logic.
It seems like creating a yaml -> .sbt converter for the simple cases would be pretty easy and might have some nice benefits.
Or better, hocon.
Dale Wijnand
@dwijnand
Mar 30 2016 15:27
Leaving everything in Scala (or quasi-Scala) removes any big jump in learning curve. It's one of the reasons I like sbt. In other tools you start learning the tool in one language, and then have to relearn a bunch of topics in the alternative more powerful language, for example in Ansible: YAML/Python, in Puppet: Puppet/Ruby, etc.
Perry
@pfn
Mar 30 2016 16:53
I also like the sbt format as is
it practically works like a declarative file for simple cases
which is excels at
it
foo := bar
Erik LaBianca
@easel
Mar 30 2016 18:13
Yeah the downside to .sbt IMO is it’s hard to programmatically modify. Think for instance of how you add dependencies to your project in npm. You can just do npm install —save <package> and npm can edit your package.json with the new dependency since the format is simple.
Or, say you wanted your IDE to be able to save changes to your sub-module back to your canonical build. I don’t see that happening in a .sbt file.
eugene yokota
@eed3si9n
Mar 30 2016 18:17
not sure how applicative it is here, but there is > session save
OlegYch
@OlegYch
Mar 30 2016 18:41
afair .sbt format was invented specifically to be 'programatically modifiable'
it's probably the only thing it's better than *.scala imo
Dale Wijnand
@dwijnand
Mar 30 2016 18:49
One of the things I'd like to do is make build.sbt easier to programmatically modify. For instance I'd like sbt-release to be able to change the version in situ rather than dedicating a file to it.
OlegYch
@OlegYch
Mar 30 2016 18:52
that's probably possible with scala-meta
but i'd say that would have very limited applicability
Erik LaBianca
@easel
Mar 30 2016 18:59
It seems like if the goal is programatic modification you will always be at a disadvantage with a format that doesn’t have ubiquitous parsers. You could always provide defaults that load from the file and can be override, for instance .settings(libraryDependencies := DependenciesFromHocon) or whatever.
Dale Wijnand
@dwijnand
Mar 30 2016 19:01
Right. I'm not sure if it's possible. But I'd like it. And I'd try to make it a module of sbt that I can use externally. Such module might be usable by ensime as well to provide sbt format support.
I speak from little experience. Just a lot of interest.
Erik LaBianca
@easel
Mar 30 2016 19:03
Cool. Any forward motion for SBT is good IMO, it’s key for scala usability and adoption imo.
Dale Wijnand
@dwijnand
Mar 30 2016 19:04
I agree.
Erik LaBianca
@easel
Mar 30 2016 19:05
I was fiddling around with sbt-extras trying to an “sbt as scala repl” mode, seems to work ok just using a workspace directory. But I was thinking for those type users, it would be awesome to be able to just scala —install org.playframework.play % 2.5.0 and suddenly things were less pretty =p Hence my earlier comment about programatic modifications of .sbt files =p
Dale Wijnand
@dwijnand
Mar 30 2016 19:05
Other uses I'd have include what it looks like you were referring to: modifying library dependencies, also in situ.
Erik LaBianca
@easel
Mar 30 2016 19:06
Yeah that would be great. My use case would be met with a library that could handle the manipulations, and most of the IDE’s would be able to use that as well.
Dale Wijnand
@dwijnand
Mar 30 2016 19:06
Right. Yeah my use case is bump a dependency version rather that add a dependency.
Yep
Erik LaBianca
@easel
Mar 30 2016 19:08
Sure. Same class of problem though. It would be great to be able to do things like sbt —check-for-updates —accept or something, too. I think for beginners the concept of a global context is good too, even though ever advanced user is going to end up relying on local package scope only.
I’d like more tools to dump and reload the dependency tree too. As it stands, I know I have some really wierd classpath combinations in my submodules and insufficient intestinal fortitude to try and dig through and figure out what they are.
Perry
@pfn
Mar 30 2016 20:01
@easel writing is easy, modification, not so much
Perry
@pfn
Mar 30 2016 20:19
dependency graph is pretty awesome though
more tools? it's the one stop shop already
Erik LaBianca
@easel
Mar 30 2016 20:19
Yeah, the output tends to be a little unmanageable though.
Perry
@pfn
Mar 30 2016 20:19
how so? I thought it's rather clean
and you can graphviz it as well
Erik LaBianca
@easel
Mar 30 2016 20:20
Well, for my project it’s riduculously huge because of all the sub modules. There may be some ways to cut it down that I just haven’t figured out though =p
Frankly I would like to be able to simplify my library dependency graph down to one list and dump and reload it like you can with pip freeze. Having each submodule potentially have it’s own set of transitive resolutions is pretty problematic when they’re all getting deployed onto one classpath anyway.
Perry
@pfn
Mar 30 2016 20:45
then have all your dependencies registered in 1 module, and have every other module depend on that
dunno what you're trying to do in any case
and why you have so many submodules
Erik LaBianca
@easel
Mar 30 2016 21:02
Well, scala.js is a big part of it, and issues with codec derivation is another chunk. That accounts for 3 layers that each require unique library dependencies right there. Shared models, shared derived stuff, then jvm/js specifics. Then add in a module for each backend service and each front-end app and you’ve got a bunch without accounting for open source forks. I’d LOVE to be able to say “here are all the blessed versions, take from them what you need but never use another version”.
Tin Pavlinic
@triggerNZ
Mar 30 2016 23:24
hi all, I have something like the following in my projectSettings in my plugin:
libraryDependencies := {
      val currentDeps = (libraryDependencies in Compile).value
      println(currentDeps)
      val coppersmithScaldingDependency = currentDeps.find(dependency => dependency.name == "coppersmith-scalding")

      val tools = coppersmithScaldingDependency.fold(
        throw new IllegalStateException("Project must have coppersmith-scalding to generate metadata")) {
        dep => dep.copy(name = "coppersmith-tools")
      }
      val result = currentDeps :+ tools

      println(s"RESULT: $result")
      result
    }
So I want to add the coppersmith-tools dependency with the same version as the coppersmith-scalding dependency
The problem I have is that println(currentDeps) outputs List(), presumably because the plugin is run before my actual build file. is there any way for the plugin to append a dependency that is computed from the user's dependencies
Tin Pavlinic
@triggerNZ
Mar 30 2016 23:58
okay, i have solved that by creating a new Configuration, and adding my libraryDependencies in Metadata: lazy val Metadata = config("metadata") extend(Compile, Runtime)
however, trying to access (fullClasspath in Runtime) still doesn't have the added library