These are chat archives for sbt/sbt

6th
Feb 2016
Sam Halliday
@fommil
Feb 06 2016 13:02
  private def projectRef(structure: BuildStructure, resolved: ResolvedProject): ProjectRef =
    structure.allProjectRefs.find(_.project == resolved.id).get
is that needed?
or is there an API call that does this?
Sam Halliday
@fommil
Feb 06 2016 13:09
hmm, I'm looking for a way to create an InputTask without using the macro api ... http://www.scala-sbt.org/0.13/docs/Input-Tasks.html all macros
I'll check the sbt source
struggling to find one
Sam Halliday
@fommil
Feb 06 2016 13:16
going back to the 0.12 docs often helps, but not so much here http://www.scala-sbt.org/0.12.4/docs/Extending/Input-Tasks.html
Sam Halliday
@fommil
Feb 06 2016 14:41
is there any way to tell if a Task has been directly invoked by the user, or if it is a transient task?
actually, that's probably irrelevant, what I really need is a way to run a dependent Task before all other dependent tasks (there is a cache clearing side effect in it)
Sam Halliday
@fommil
Feb 06 2016 18:29
oh, awesome. Either the sources or resources task depends on compile
sigh
it's resources. Oh joy.
Sam Halliday
@fommil
Feb 06 2016 19:52
I just released v1 of sbt-big-project https://github.com/fommil/sbt-big-project/
Dale Wijnand
@dwijnand
Feb 06 2016 20:02
nice one
Sam Halliday
@fommil
Feb 06 2016 20:07
I think my sbt foo levelled up significantly writing this one
Dale Wijnand
@dwijnand
Feb 06 2016 20:13
Indeed, nothing like writing a plugin to help you understand the system better.
Jon Pretty
@propensive
Feb 06 2016 20:16
"Become a better driver by designing and building your own carburettor."
Dale Wijnand
@dwijnand
Feb 06 2016 20:22
that's a little unfair, how about become a better driver by changing your own brake pads..
or changing your own wheels for snow tires
Jon Pretty
@propensive
Feb 06 2016 20:31
Maybe it is unfair. I've had particularly bad experience with SBT recently. Part of that has been trying to unpick a complex build where a load of things have been implemented with plugins, and it's been frustrating as hell. I rewrote the build with plain Scala, and it's 1/4 the number of LoC, took me 1/10 the time to get working, and is faster to run and trivial to understand the sequence of things that happen, when they happen, and why. It doesn't manage dependencies, though—that's the main disadvantage.
Anyway, I feel bad being so negative about SBT. I know most people have had a lot more success with it than I have! I just seem to get repeatedly burned...
matanster
@matanster
Feb 06 2016 20:36
@propensive you're not alone in that :)
imo we eventually need a "dotty" for sbt

Something else ― anyone here running sbt through sbt-extras?
This used to work for me before making the switch, or maybe before sbt 0.13.9

sbt -mem 256
[info] Loading global plugins from....
[info] Loading project definition from ....
[info] Set current project to app
[warn] The - command is deprecated in favor of onFailure and will be removed in 0.14.0

Erik LaBianca
@easel
Feb 06 2016 21:35
sbt-extras likes .jvmopts for such things
Mark van Buskirk
@LogicalTime
Feb 06 2016 21:42
@propensive I recently switched to the Build.scala style of using sbt. I feel much more secure with straight scala rather than the dsl. Is that what you did?
Dale Wijnand
@dwijnand
Feb 06 2016 21:44
@matanster sbt-extras doesn't support -mem, use -J-Xms and -J-Xmx
@propensive is this project public anywhere? I'd like to see what you struggled with
Jon Pretty
@propensive
Feb 06 2016 21:49
No, it's closed source, and it had enough quirks to warrant a lot of guesswork on my part. The biggest problem was struggling to understand both the intent from the code. I'm an SBT novice, which has a lot to do with it.
Thanks for the offer, anyway. I would much rather be solving the problems with help, than moaning about them all the time...
Mark van Buskirk
@LogicalTime
Feb 06 2016 21:51
@propensive @dwijnand Probably too simple an example but I think you might appreciate this Build.scala I found from deanwampler@typesafe: https://github.com/deanwampler/spark-workshop/blob/master/project/Build.scala
Dale Wijnand
@dwijnand
Feb 06 2016 21:52
Being an sbt novice and being tasked with unpicking a complex, multi-plugin build without any guidance sounds preeeetty rough..
I can understand your frustration
Jon Pretty
@propensive
Feb 06 2016 21:53
@LogicalTime Oh, sorry, just saw your earlier response. It was already in Build.scala style. Maybe that helped slightly... :)
Mark van Buskirk
@LogicalTime
Feb 06 2016 21:55
@propensive Well then you are on pretty solid ground methinks. Did you have trouble with a particular plugin?
Dale Wijnand
@dwijnand
Feb 06 2016 21:55
There's only so much the build.sbt is different from Scala tbh, and there are good reasons to use it.
Mark van Buskirk
@LogicalTime
Feb 06 2016 21:57
What advantages do you get from using build.sbt? Cause you lose the ability to make top level scala objects right? So hopefully we get something good for that.
Dale Wijnand
@dwijnand
Feb 06 2016 21:59
you can use anonymous classes instead:
val Deps = new {
  val foo = "1.2.3"
}
you get plugin's autoImport things auto-imported
you get sbt._, Keys._ auto-imported
you get to not have to declare an object and nest everything..
no commas at the top level..
Mark van Buskirk
@LogicalTime
Feb 06 2016 22:02
nice point. They should remind people of that on the sbt documentation when they say "Top-level objects and classes are not allowed in build.sbt. Those should go in the project/ directory as full Scala source files."
With multi project build it just feels a little cleaner to explicitly make that root project and treat it like the other projects and I do multiproject builds a bunch.
Mark van Buskirk
@LogicalTime
Feb 06 2016 22:08
For a single project build, I agree the build.sbt looks super nice and clean. I'll probably use it more once I have played around with everything for a while using Build.scala. I just like not having a lot of stuff magically going on unless I know exactly what that magic is. That's why I like the Build.scala right now since I'm still learning a bunch.
matanster
@matanster
Feb 06 2016 22:14
Actually, it was previously stated that the build.sbt option is the intended one for anything but power users, but you're not the first one to prefer it nonetheless
Mark van Buskirk
@LogicalTime
Feb 06 2016 22:22
@matanster yeah I read that. I'
I'd argue that for learning it is nice to go the Build.scala route. Then you are in "scala-world" and can more easily explore stuff. Just being able to see that your build inherits the trait Build and being able to click on it is nice. I know what stuff is in scope and where it comes from. I can ctrl click on sbt._ and see what is coming in from there, etc etc.
Perry
@pfn
Feb 06 2016 22:25
I absolutely prefer using build.sbt
Dale Wijnand
@dwijnand
Feb 06 2016 22:25
I'd say the opposite. Start with "this is what I know what to do with the build" in build.sbt, then eventually start to piece things together with the underlyning Scala source
Perry
@pfn
Feb 06 2016 22:26
can get all the discoverability the same way
intellij recognizes everything in there
Dale Wijnand
@dwijnand
Feb 06 2016 22:26
yep
Perry
@pfn
Feb 06 2016 22:27
I only fall back to scala files when what I want cannot. be expressed in sbt files
Mark van Buskirk
@LogicalTime
Feb 06 2016 22:27
I like that both options are there, just excited about the Build.scala route right now. Once I know more I'll probably usually use the build.sbt route since it's so nice and clean and automatically brings in those imports.
Make sense?
matanster
@matanster
Feb 06 2016 22:28
@easel @dwijnand thanks a lot for answering before about Xmx
Mark van Buskirk
@LogicalTime
Feb 06 2016 22:32
BTW, I was reading this article the other day and was sad to see gradle users flooding the comments to use gradle over sbt and no experienced sbt users responding: https://codeascraft.com/2014/09/30/building-a-better-build-our-transition-from-ant-to-sbt/
OlegYch
@OlegYch
Feb 06 2016 23:03
LogicalTime i like that there is considerably less magic in *.scala
Dale Wijnand
@dwijnand
Feb 06 2016 23:04
just your regular Scala magic :)
OlegYch
@OlegYch
Feb 06 2016 23:04
fwiw i think it's easier for people how are using scala
Sam Halliday
@fommil
Feb 06 2016 23:09
@LogicalTime that's because there are extremely few experienced sbt developers
Mark van Buskirk
@LogicalTime
Feb 06 2016 23:11
@fommil let's change that!
Sam Halliday
@fommil
Feb 06 2016 23:11
The less macros, and the more Scala, that i use in sbt the more I'm able to get done.
I despise .sbt files. They are only good for trivial projects.