Skip to content

Conversation

@eed3si9n
Copy link
Member

@eed3si9n eed3si9n commented Dec 13, 2021

This is a work-in-progress port to Scala 3, some of which documented as sudori:

@eed3si9n

This comment was marked as outdated.

@eed3si9n eed3si9n force-pushed the wip/sbt-2.x branch 4 times, most recently from 3f47daf to ed2d460 Compare September 27, 2022 06:02
@eed3si9n eed3si9n force-pushed the wip/sbt-2.x branch 7 times, most recently from 2f4b042 to f0c1976 Compare October 4, 2022 07:30
@eed3si9n eed3si9n force-pushed the wip/sbt-2.x branch 14 times, most recently from 820528e to f498cb2 Compare October 11, 2022 04:59
@eed3si9n eed3si9n force-pushed the wip/sbt-2.x branch 6 times, most recently from 9e814b4 to 8181a33 Compare January 20, 2023 18:48
@eed3si9n eed3si9n force-pushed the wip/sbt-2.x branch 2 times, most recently from 2cdd136 to 25b835d Compare January 20, 2023 23:47
@eed3si9n eed3si9n marked this pull request as ready for review January 26, 2023 20:19
@eed3si9n eed3si9n changed the title [wip] sbt 2.x sbt 2.x (sbt in Scala 3) Jan 26, 2023
@@ -20,6 +20,7 @@ import sbt.internal.util.Attributed
import Def.{ ScopedKey, Setting }
import Keys._
import Configurations.{ Compile, Runtime }
import sbt.ProjectExtra.{ extract, runUnloadHooks, setProject }

Choose a reason for hiding this comment

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

With the changes to LoadBuildConfiguration, it looks like there may need to be an update to the def build method, or else global plugins fail to load, due to being passed the wrong BASE directory:

java.lang.RuntimeException: /Users/julianpeeters/.sbt/2.0.0-alpha6-SNAPSHOT/plugins/global.sbt cannot be mapped using the root paths
Map(
  BASE -> /Users/julianpeeters/Workspace/hello-global,
  SBT_BOOT -> /Users/julianpeeters/.sbt/boot,
  IVY_HOME -> /Users/julianpeeters/.ivy2,
  JAVA_HOME -> /Users/julianpeeters/.sdkman/candidates/java/17.0.1-oracle
)
  def build(base: File, s: State, config: LoadBuildConfiguration): (BuildStructure, State) = {
    val newConverter =
      MappedFileConverter(config.converter.rootPaths2.toMap.updated("BASE", base.toPath), false)
    val newInject =r
      config.injectSettings.copy(global = config.injectSettings.global ++ globalPluginSettings)
    val globalConfig = config.copy(
      injectSettings = newInject,
      pluginManagement = config.pluginManagement.forGlobalPlugin,
      converter = newConverter
    )

See https://eed3si9n.com/simplifying-sbt-with-common-settings/

Problem
-------
The behavior of bare settings is confusing in a multi-project build.
This is partly due to the fact that to use `ThisBuild` scoping
the build user needs to be aware of the task implementation,
and know if the task is already defined at project level.

Solution
--------
This changes the interpretation of the baresettings to be common
settings, which works similar to the way `ThisBuild` behaves in sbt 1.x,
but since this would be a simple append at project-level, it should
work for any tasks or settings.
Problem
-------
In sbt 1, platform cross building is implemented using in the user-land
using `%%%` operator, which clevery handles both Scala cross building
and appending platform suffix like sjs1.
However, in general symbolic `%%%` is confusing, and hard to explain.

Solution
--------
In sbt 2, we should subsume the idea of platform cross building,
so `%%` can act as the current `%%%` operator.
This adds a new setting called `platform`, which defaults to
`Platform.jvm` by default.
When a subprojects sets it to `Platform.sjs1`, `ModuleID`s defined using
`%%` operator will inject the platform suffix `_sjs1` **in addition**
to the Scala binary suffix `_2.13` etc.

Note: Explicit JVM dependencies will now require `.platform(Platform.jvm)`.
adpi2
adpi2 approved these changes Oct 17, 2023
Copy link
Member

Choose a reason for hiding this comment

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

I suggest we remove those Scala 2 files if we don't need to cross-compile collectionProj anymore.

Comment on lines 47 to +54
// Construct these StringTypeTags manually, because they're used at the very startup of sbt
// and we'll try not to initialize the universe by using the StringTypeTag.apply that requires a TypeTag
// A better long-term solution could be to make StringTypeTag.apply a macro.
lazy val stringTypeTagThrowable = StringTypeTag[Throwable]("scala.Throwable")
lazy val stringTypeTagTraceEvent = StringTypeTag[TraceEvent]("sbt.internal.util.TraceEvent")
lazy val stringTypeTagSuccessEvent = StringTypeTag[SuccessEvent]("sbt.internal.util.SuccessEvent")
lazy val stringTypeTagThrowable = StringTypeTag.manually[Throwable]("java.lang.Throwable")
lazy val stringTypeTagTraceEvent =
StringTypeTag.manually[TraceEvent]("sbt.internal.util.TraceEvent")
lazy val stringTypeTagSuccessEvent =
StringTypeTag.manually[SuccessEvent]("sbt.internal.util.SuccessEvent")
Copy link
Member

Choose a reason for hiding this comment

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

Since StringTypeTag.apply is a macro, we don't need to initialize those manually anymore.

Comment on lines -48 to +49
def ignoreResult[T](f: => T): Unit = macro Macro.ignore
def ignoreResult[A](f: => A): Unit =
f; ()
Copy link
Member

Choose a reason for hiding this comment

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

Why was it a macro and it is not anymore? Should we inline it?

Comment on lines 239 to -241
@deprecated("Use LineReader apis", "1.4.0")
private[sbt] object JLine {
@deprecated("For binary compatibility only", "1.4.0")
protected[this] val originalIn = new FileInputStream(FileDescriptor.in)

Copy link
Member

Choose a reason for hiding this comment

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

Should we remove JLine completely? It only contains deprecated methods.

/**
* Arity-generic List. An abstraction over structured Tuple/List type constructor `X1[f[a]]`.
*/
trait AList[K[F[_]]]:
Copy link
Member

Choose a reason for hiding this comment

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

AList on tuples was much more simpler to understand.

We do need to treat AList like a typeclass after all because
sbt.std.Transform.uniform needs to traverse over a List,
and we won't be able to magically connvert a List into a tuple.

We can use Tuple.fromArray(list.toArray) instead, if it doesn't impact the performance too much.

Comment on lines +161 to -157

// bridge.runInParallel(
// sourcePath,
// bufferLog,
// args.toArray,
// launchOpts.toArray,
// callback,
// scalaVersion,
// sbtVersion,
// classpath.toArray,
// instances
// )
bridge.runInParallel(
sourcePath,
bufferLog,
args.toArray,
launcherJar,
"java",
launchOpts.toArray,
callback,
scalaVersion,
sbtVersion,
classpath.toArray,
Copy link
Member

Choose a reason for hiding this comment

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

Do you remember the purpose of these changes?

ThisBuild / scalafmtOnCompile := !(Global / insideCI).value
ThisBuild / Test / scalafmtOnCompile := !(Global / insideCI).value
ThisBuild / turbo := true
// ThisBuild / turbo := true
Copy link
Member

Choose a reason for hiding this comment

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

Why disabling turbo mode? Does it make the tests flaky?

Comment on lines +44 to +52
pollInterval,
pushRemoteCacheArtifact,
sbt.nio.Keys.outputFileStamper,
sbt.nio.Keys.watchTriggers,
serverConnectionType,
serverIdleTimeout,
shellPrompt,
sLog,
traceLevel,
Copy link
Member

Choose a reason for hiding this comment

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

Do you have a clue why we need to add more keys to excludeLintKeys?

Copy link
Member

Choose a reason for hiding this comment

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

Do you remember why you renamed project to project1?

Copy link
Member

Choose a reason for hiding this comment

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

LinterDS and TaskLinterDSL are not ported? What are they supposed to do? Should we try to port them or remove them?

@eed3si9n
Copy link
Member Author

Many projects are configured with cross-compilation and many of them don't cross compile anymore. Do you know if there are some projects that we should keep cross-compiling? Or if we should drop cross-compilation in this branch.

We should probably drop Scala 2.x cross build.

Should we avoid using the new syntax to make it smoother to port back and from sbt 1.x

In some situations maybe, but you may have noticed I am a big fan of the new syntax, so I think we should just use Scala 3 as intended with all the bells and whistles.

@eed3si9n
Copy link
Member Author

I'm on board with merging it now and continue working on the migration in separate PRs.

Yea. Let's merge this as-is, and I'll come back to this PR to respond to comments and todos.

@eed3si9n eed3si9n merged commit 11cc8b5 into sbt:develop Oct 22, 2023
@adpi2 adpi2 mentioned this pull request Dec 14, 2023
31 tasks
@eed3si9n eed3si9n deleted the wip/sbt-2.x branch December 14, 2023 14:17
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