Switch to scala-module-plugin, sbt 0.13.1

[adriaanm]

No description provided.

[adriaanm]

Review by @gkossakowski

[retronym]

LGTM

'Tis a thing of beauty.

[adriaanm]

Why, thank you, good Sir.

[gkossakowski]

LGTM.

It's great we are centralizing configuration of our modules. Would it make sense to mention at https://github.com/scala/sbt-scala-modules what kind of boilerplate the plugin centralizes? I lost track which settings are temporary work-arounds and which are permanent because modules deviate from sbt defaults.

[retronym]

BTW, after we cut the cord in -xml, -parser-combinators, and -continuations, is anyone using partest outside of scala/scala? If not, I tend to think we should move it back into that repo in 2.12. Would save the "what goes in partest vs partest-extras" question. (I think too many the former currently has too many dependencies of compiler internals).

I do like the standard SBT buildability, BTW. But we're aiming for that in scala/scala, anyways.

[gkossakowski]

BTW, after we cut the cord in -xml, -parser-combinators, and -continuations, is anyone using partest outside of scala/scala? If not, I tend to think we should move it back into that repo in 2.12. Would save the "what goes in partest vs partest-extras" question. (I think too many dependencies of compiler internals ended up in partest).

I tend to agree. Partest was meant to be used by compiler plugin authors as well (that's why it was shipped with Scala distribution) but there are not that many plugin authors in the wild. Ironically enough, our own plugin (continuations) doesn't have any partest tests.

When we were modularizing we had to move partest out of scala/scala due to our dependency structure and the state of our tests.

We are in better position now to keep partest private to scala/scala.

[retronym]

I've co-opted a related ticket to track this: https://issues.scala-lang.org/browse/SI-7836

[som-snytt]

An excellent co-optation. However, very recently I wanted the classic DNC test, "this does not compile." There's an issue for various partest facilities; it would be too bad to have to wait on a scala release for such improvements (assuming they are forthcoming).

[retronym]

We currently copy/paste a few lines to do this:

scala/scala-xml@9c055a1

[retronym]

I would probably factor this out to scala-compiler.jar, near ToolBox, rather than introduce a new micro-module.

[adriaanm]

One reason to keep partest separate is to force ourselves to start building a stable platform in addition to the macros out there. Partest only exercises a small part of the api, of course, but we have to start somewhere.

The second reason: maybe other back-ends could use it? /cc @sjrd

[adriaanm]

It's great we are centralizing configuration of our modules. Would it make sense to mention at https://github.com/scala/sbt-scala-modules what kind of boilerplate the plugin centralizes? I lost track which settings are temporary work-arounds and which are permanent because modules deviate from sbt defaults.

I don't think there are any work arounds left. Still good to document the plugin, I agree.

[adriaanm]

Also, in general, I think separate repos are a good thing -- I've heard several times that people felt less intimidated to contribute to a more focussed repository, so they don't have to worry about breaking anything they're not interested in, don't have to figure out what's relevant, what isn't. It also makes for faster PR validation.

[som-snytt]

Yeah, now they only have to worry about breaking the gazillion downstream community builds, with source compatibility. But the point about intimidation factor still holds: if anything breaks, retronym will step in to assist. And retronym is like the opposite of intimidating. Kind of warm and fuzzy, in fact.

[sjrd]

The second reason: maybe other back-ends could use it?

Scala.js definitely benefits from partest being released as a separate artifact that I can depend on and invoke from sbt, yes! That is how we manage to run the partest suite against Scala.js in our 2.11 branch (btw, we now have only 78 tests failing among those that are supposed to pass. almost there!).

[retronym]

We can still publish. But I propose that we don't test the compiler with the previous published release of partest, and instead build a fresh copy each time. Let's discuss for 2.12