-
Notifications
You must be signed in to change notification settings - Fork 50
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
Introduce tlCrossRootProject
#43
Introduce tlCrossRootProject
#43
Conversation
lazy val root = tlCrossRootProject.aggregate( | ||
kernel, | ||
noPublish, | ||
settings, | ||
github, | ||
versioning, | ||
mima, | ||
sonatype, | ||
ciSigning, | ||
sonatypeCiRelease, | ||
ci, | ||
core, | ||
ciRelease) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here it is in action. Nothing fancy. Regardless of the name of the val
it's assigned to, it always generates projects called root
—I didn't want to fuss with macros.
ci/build.sbt
Outdated
addSbtPlugin("org.scala-js" % "sbt-scalajs" % "1.0.0") // scala-steward:off | ||
addSbtPlugin("org.scala-native" % "sbt-scala-native" % "0.4.0") // scala-steward:off |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the CI plugin is trying not to be too prescriptive, and we don't use the JS/native plugins except to check for their presence on a project, these versions should be sufficient.
Hopefully this won't interfere with our other updates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the Native plugin have have the non-breaking track record of Scala.js? What is the risk of this dependency to all the people who don't aspire to support Native, which I think is still most Typelevel projects?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All fair points, I'm not familiar enough with native but it's still much more in development. In any case, I ended up removing it because my plugin detection idea wasn't working. See #43 (comment).
|
||
private def aggregateImpl(projects: Project*): CrossRootProject = { | ||
|
||
val jsProjects = projects.filter(p => Plugins.satisfied(p.plugins, Set(ScalaJSPlugin))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, these filters don't work like I expected wanted them to—Plugins.satisfied
is too strict.
val jsProjects = | ||
projects.filter(_.plugins.toString.contains("org.scalajs.sbtplugin.ScalaJSPlugin")) | ||
|
||
val nativeProjects = | ||
projects.filter( | ||
_.plugins.toString.contains("scala.scalanative.sbtplugin.ScalaNativePlugin")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Too horrible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like to minimize how much users need to think about cross-platform, but I'm worried that extra dependenare going to make it hard for the typical project that just wants an easy way to publish for the JVM.
ci/build.sbt
Outdated
addSbtPlugin("org.scala-js" % "sbt-scalajs" % "1.0.0") // scala-steward:off | ||
addSbtPlugin("org.scala-native" % "sbt-scala-native" % "0.4.0") // scala-steward:off |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the Native plugin have have the non-breaking track record of Scala.js? What is the risk of this dependency to all the people who don't aspire to support Native, which I think is still most Typelevel projects?
Yeah, that's a fair point. I agree we should leave dependencies to native out, but SJS I think is stable enough? Alternatively, all of this could be moved to separate plugins actually: |
I fear heading for 2^n plugins for n supported use cases. What is the approximate burden on a JVM-only project if the Scala.js machinery is present? |
Just the Scala.js plugin on the sbt classpath. They can ignore this Edit: oh, I also put sbt-crossproject on the sbt classpath (this is another stable one I think). But this is not really necessary: I just added it as part of the catch-all superplugin. |
Seq(GlobalScope / onLoad ~= { (f: State => State) => | ||
f andThen { s: State => | ||
BasicCommands.addAlias(BasicCommands.removeAlias(s, name), name, contents) | ||
} | ||
}) | ||
|
||
implicit def tlCommandOps(commands: List[String]): TlCommandOps = new TlCommandOps(commands) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know implicits aren't the most popular. Thoughts on this mkCommand
syntax to help define the aliases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this one does enough to justify the magic. If we frequently stubbed our toe quoting semi-colons, maybe, but we don't, and the helper doesn't fix that anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, I'll scrap it.
These latest changes try to DRY the command alias stuff, since we end up with many more of these to handle |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to try this on an application, where cross-platform doesn't tend to be needed, and make sure that none of this interferes. But it seems reasonable.
Agree on testing 👍 If I've done it right, it shouldn't interfere because the |
This PR solved sbt/sbt-github-actions#3. |
Fixes #34.
This introduces a
tlCrossRootProject
helper for creating the "root" aggregate project. It:root
,rootJVM
,rootJS
, androotNative
projects (all set to no-publish)root
itself collects everything)I've demonstrated/tested
tlCrossRootProject
on this build, where it adds a singleciJVM
job to the matrix since there are no JS or native project in this build. (Note that we now also have arootJS
androotNative
project that are empty, just a small nuisance I hope.)