These are chat archives for sbt/sbt

15th
Jun 2015
Sergio Tudela Romero
@sergiotudela
Jun 15 2015 11:07
Hi, JMH 1.10 has been released, has anyone tested for compatibility with https://github.com/ktoso/sbt-jmh ?
eugene yokota
@eed3si9n
Jun 15 2015 11:37
@sergiotudela I'd say open a github issue on the plugin to get author's attention
Sergio Tudela Romero
@sergiotudela
Jun 15 2015 11:37
@eed3si9n cool, thanks!
In fact, theres is a channel in Gitter… sorry!
eugene yokota
@eed3si9n
Jun 15 2015 11:42
@sergiotudela no worries. plugin development is more on-topic than most other conversation that takes place here
Sergio Tudela Romero
@sergiotudela
Jun 15 2015 11:43
:smile:
Vivian Pennel
@Vp3n
Jun 15 2015 11:57

Hi everyone , i’m new around here :). Not sure if my question is in the right place but :
I’m trying to develop a sbt plugin involving sbt-twirl.
if i add the dependency in plugins.stb as addSbtPlugin("com.typesafe.sbt" % "sbt-twirl" % "1.1.1 ) this works in my build (can set twirl) settings but i can’t acccess sbt-twirl in the classpath of my autoplugin (src/main/**)
If i add dependency with libraryDependencies (either in the projet or in plugins.sbt) sbt-twirl cannot be found.

How can i use sbt-twirl as a ‘usable’ dependency in my AutoPlugin? Is this a twirl specific issue :( ?

eugene yokota
@eed3si9n
Jun 15 2015 11:59
@Vp3n You have to add addSbtPlugin in build.sbt to make a derivative plugin. See https://github.com/sbt/sbt-houserules/blob/master/build.sbt
Vivian Pennel
@Vp3n
Jun 15 2015 12:02
Thanks this works fine ! Do i need to enablePlugins in my build too in this case ?
eugene yokota
@eed3si9n
Jun 15 2015 12:02
not if you require it from your plugin and enable your plugin
Vivian Pennel
@Vp3n
Jun 15 2015 12:02
Ok
Thanks :)
Josh Suereth
@jsuereth
Jun 15 2015 13:26
For anyone curious on sbt's representation of its own build state: https://github.com/ensime/ensime-server/issues/669#issuecomment-112069183
Dale Wijnand
@dwijnand
Jun 15 2015 13:32
Very nice Josh.
Josh Suereth
@jsuereth
Jun 15 2015 13:33
the next question is if we put that in scala-sbt.org or wait to see if we break the APIs....
I'm just glad we didn't answer that BEFORE autoplugins, since it all changed :)
Dale Wijnand
@dwijnand
Jun 15 2015 13:34
When was autoplugins? 0.13?
Josh Suereth
@jsuereth
Jun 15 2015 13:35
0.13.5
with fixes/shifts in 0.13.6
I reworked the entire loading mechanism in 0.13.6
Some of those APIs I mention were part of instability. We perserved BC, but only barely
Simeon H.K. Fitch
@metasim
Jun 15 2015 13:36
@jsuereth This is gold. Put in http://www.scala-sbt.org/0.13/docs/Faq.html? Or howto section?
Dale Wijnand
@dwijnand
Jun 15 2015 13:38
Btw I had a quick go at adding sbt-mima to sbt itself, not having done it before, and it's very unhappy about, for instance, new methods on traits..
Josh Suereth
@jsuereth
Jun 15 2015 13:38
As it should be
The key to mima is filtering out things that you allow to break
OR e.g. MiMa is unaware of "sealed"
or "private[sbt]"
Dale Wijnand
@dwijnand
Jun 15 2015 13:39
that last one yeah should be configurable
Josh Suereth
@jsuereth
Jun 15 2015 13:39
We use that trick a lot. A lot of BC breakages are private-to-sbt so no user is affected
Josh Suereth
@jsuereth
Jun 15 2015 13:40
Cool! What kind of errors are you seeing?
specifically
Dale Wijnand
@dwijnand
Jun 15 2015 13:40
for instance my adding inThisBuild in some Project-something trait
Josh Suereth
@jsuereth
Jun 15 2015 13:42
OH, right, is that trait sealed?
There are a few traits we consider "ours", i.e. all instantiations are only done via sbt
eugene yokota
@eed3si9n
Jun 15 2015 13:43
figuring out what part of sbt should be covered by mima post 1.x would be an interesting project
Josh Suereth
@jsuereth
Jun 15 2015 13:43
Right, so that trait is "ours" in the sense that we expect no one to ever extend it but us
We should explicitly document that
i.e. it's not "users should extend this and pass to sbt" kind of trait, it's more a "here's a public API" kind of trait, so we can hide our impl class
But we can't seal it because the impl class is in a different file. Wish we had a term for sucha thing
Dale Wijnand
@dwijnand
Jun 15 2015 13:45
the tyranny of the source file? :P
eugene yokota
@eed3si9n
Jun 15 2015 13:45
"can't touch this"
Josh Suereth
@jsuereth
Jun 15 2015 13:45
ALso, you can't add sealed to a trait without breaking BC
Josh Suereth
@jsuereth
Jun 15 2015 13:45
"@McHammer trait"
Dale Wijnand
@dwijnand
Jun 15 2015 13:46
My intent was to explicitly exempt all warnings, open a pull-request and have a conversation about it there.
Josh Suereth
@jsuereth
Jun 15 2015 13:47
sounds good
eugene yokota
@eed3si9n
Jun 15 2015 13:47
I'd argue putting mima on 0.13 would be futile effort
Dale Wijnand
@dwijnand
Jun 15 2015 13:47
But I like the idea of being able to configure mima to ignore breakages in specified packages (ie. private[sbt])
Josh Suereth
@jsuereth
Jun 15 2015 13:47
I'm still trying to remove all the BC breakages I have in my scala/pickling branch
Yeah, I like that idea too
Dale Wijnand
@dwijnand
Jun 15 2015 13:49
@eed3si9n Why?
eugene yokota
@eed3si9n
Jun 15 2015 13:49
0.13 code base doesn't distinguish imple from API
that's the whole point of starting anew with sbt 1.0
we should actually share sbt 1.0 "technical spec" with you
Josh Suereth
@jsuereth
Jun 15 2015 13:51
Yeah, odds that we get to write a ton of docs right now are low, so we should just release half-ideas to teh community so you can see the vision, and help us flesh it out
But basically, we want to take our API and have community involvement in making things 1.0 as we migrate stuff out of sbt/sbt into modules
Dale Wijnand
@dwijnand
Jun 15 2015 13:52
sure
Josh Suereth
@jsuereth
Jun 15 2015 13:52
Eventually our public API may be all external, we'll see.
BUT, DependencyManagement and incremental compiler are the next big modules to tackle and iron out an API for
I think we did a good job with pickling/serialization, but if oyu have any input to sbt-io, please look at https://github.com/sbt/io
I personally didn't think there was a lot to improve on in sbt-io besides maybe fixing Java's limitations on file API (i.e. async file I/O is all but impossible)
Dale Wijnand
@dwijnand
Jun 15 2015 13:54
I like the direction for 1.0, but given we do deal with bincompat in 0.13 I'd rather a tool confirm things then try and eyeball then, even if it means making some wide exclusions, say something that does sbt.ProjectExtra.*)
Dale Wijnand
@dwijnand
Jun 15 2015 13:56
thanks, I'll have a read tonight
eugene yokota
@eed3si9n
Jun 15 2015 13:57
I need your gmail addy to give you edit rights
is it your handle + gmail.com?
Dale Wijnand
@dwijnand
Jun 15 2015 13:57
my main is dale.wijnand + gmail.com
Dale Wijnand
@dwijnand
Jun 15 2015 14:09
Going back to build units, that ensime comment gave me a little insight, as I was unsure whether to use them all in sbt-project-graph: https://github.com/dwijnand/sbt-project-graph/blob/v0.1.0/src/main/scala/com/dwijnand/sbtprojectgraph/SbtProjectGraphPlugin.scala#L18-L19
I guess if typically only the main unit is of interest, I'll leave the current behaviour the default and just make it configurable..
Simeon H.K. Fitch
@metasim
Jun 15 2015 14:17
@jsuereth Would you be willing to gist your markdown from ensime/ensime-server#669
Josh Suereth
@jsuereth
Jun 15 2015 14:50
sure
Simeon H.K. Fitch
@metasim
Jun 15 2015 14:54
Thanks! A more natural link destination for my notes :-)
Simeon H.K. Fitch
@metasim
Jun 15 2015 14:56
w00t!
Much appreciated.