Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sbt 1.4.0 #168

Merged
merged 2 commits into from
Oct 6, 2020
Merged

sbt 1.4.0 #168

merged 2 commits into from
Oct 6, 2020

Conversation

bjaglin
Copy link
Collaborator

@bjaglin bjaglin commented Oct 5, 2020

The second commit works around sbt/sbt#5647, which can be observed when the client uses sbt 1.4.0 (independently of the version we build with/against here) and defines scalafixCaching.

scalafix := scalafixInputTask(config).evaluated,
scalafix := {
// force detection of usage of `scalafixCaching` to workaround https://github.com/sbt/sbt/issues/5647
val _ = scalafixCaching.?.value
Copy link
Collaborator Author

@bjaglin bjaglin Oct 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

val cachingRequested = scalafixCaching.or(scalafixOnCompile).value
is not picked up by sbt inspect (as of sbt 1.4.0), so this makes a dummy lookup for the sake of materializing the usage

 sbt:sbt-scalafix> inspect actual scalafixCaching
 [info] Setting: Boolean = true
 [info] Description:
 [info] 	Cache scalafix invocations (off by default, on if scalafixOnCompile := true).
 [info] Provided by:
 [info] 	ProjectRef(uri("file:/home/bjaglin/git/projects/sbt-scalafix/"), "sbt-scalafix") / scalafixCaching
 [info] Defined at:
 [info] 	/home/bjaglin/git/projects/sbt-scalafix/build.sbt:48
+[info] Reverse dependencies:
+[info] 	Test / scalafix
+[info] 	Compile / scalafix
 [info] Delegates:
 [info] 	scalafixCaching
 [info] 	ThisBuild / scalafixCaching
 [info] 	Global / scalafixCaching

@bjaglin bjaglin marked this pull request as ready for review October 5, 2020 22:44
@bjaglin bjaglin requested a review from mlachkar October 5, 2020 22:44
Copy link
Member

@adpi2 adpi2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems legitimate.

I wonder if this workaround is still needed though:

// workaround https://github.com/sbt/sbt/issues/3572 by invoking directly what Def.inputTaskDyn would via macro
InputTask
.createDyn(InputTask.initParserAsInput(scalafixCompletions(_.parser)))(
Def.task(shellArgs => scalafixTask(shellArgs, config))
)

The task graph would be simplified with a single level of dynamicity instead of two.

@bjaglin
Copy link
Collaborator Author

bjaglin commented Oct 6, 2020

I wonder if this workaround is still needed though:

Unfortunately, even if it was fixed in 1.4.0 (I don't think it is), we would still need to keep the hack for compatibility with older 1.x clients. The first commit bumps the version of sbt for this build, but the sbt API build against and the runtime we run scripted with remains unchanged, see:

sbt-scalafix/build.sbt

Lines 53 to 66 in 5238ad7

sbtVersion in pluginCrossBuild := {
// keep this as low as possible to avoid running into binary incompatibility such as https://github.com/sbt/sbt/issues/5049
scalaBinaryVersion.value match {
case "2.10" => "0.13.17"
case "2.12" => "1.2.1"
}
}
scriptedSbt := {
// first releases that can build 2.13 (as they bring a Zinc version with a compiler-bridge published for 2.13)
scalaBinaryVersion.value match {
case "2.10" => "0.13.18"
case "2.12" => "1.2.7"
}
}
.

@bjaglin bjaglin merged commit 8284c35 into scalacenter:master Oct 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants