-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Migrate to sbt-typelevel #4160
Migrate to sbt-typelevel #4160
Conversation
project/plugins.sbt
Outdated
val sbtTypelevelVersion = "0.4.7" | ||
addSbtPlugin("org.typelevel" % "sbt-typelevel-ci-release" % sbtTypelevelVersion) | ||
addSbtPlugin("org.typelevel" % "sbt-typelevel-settings" % sbtTypelevelVersion) | ||
addSbtPlugin("org.typelevel" % "sbt-typelevel-site" % sbtTypelevelVersion) |
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 forgot to mention: in the end, I didn't actually migrate to sbt-typelevel since that would require adding copyright headers to all the files. Instead we use a combination of sbt-typelevel-ci-release and sbt-typelevel-settings. So the build still has a little more boilerplate than it could, but it's okay.
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 see a particular reason not to bite the bullet and add the headers, though it would be nice to get this substantial work to a landing.
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.
Yep, super easy to make that change. Mostly it just creates a massive diff :)
Also, I wasn't completely certain what to make of Cats' COPYING which includes a Scalaz notice as well. E.g. whether it's appropriate to put a blanket license over every file.
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.
In http4s, we generate our copyright and also preserve the original copyright on derived files. This is a fairly common practice, and one that doesn't irritate the tooling.
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.
Right, http4s has been very diligent about that which helped. But AFAICT not a single file in Cats has a copyright header, whether its derived or not.
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.
Oh, I see. I don't know how we'd go back and add that now. I say we made a good faith effort with the blanket COPYING file, and I'd be happy to add a second header if anyone cares enough to point out the derived works.
@deprecated("Added for bincompat", "2.8.0") | ||
@cats.compat.targetName("catsInstancesForId") | ||
def catsInstancesForIdCompat2_6_1: Comonad[Id] = | ||
cats.catsInstancesForId |
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.
This is the fix for #4062. Added @targetName
as a dummy annotation in Scala 2 so we don't have to split this file (I tried compat trait
s first and it didn't work).
private[instances] object instances { | ||
private[instances] object StaticMethods { |
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.
Fixes #4149.
@@ -0,0 +1,166 @@ | |||
ThisBuild / mimaBinaryIssueFilters ++= { |
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 moved these to their own file so they don't clutter up the build.sbt
.
build.sbt
Outdated
Compile / packageSrc / mappings ++= { | ||
val base = (Compile / sourceManaged).value | ||
(Compile / managedSources).value.map { file => | ||
file -> file.relativeTo(base).get.getPath | ||
} | ||
}, |
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'd like to upstream this in typelevel/sbt-typelevel#239.
build.sbt
Outdated
file -> file.relativeTo(base).get.getPath | ||
} | ||
}, | ||
scalacOptions ~= { _.filterNot(x => x.startsWith("-Wunused:")) }, |
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.
This was the most disappointing thing. Seems that Cats has got lots and lots of unused warnings. So we have to disable them if we want fatal warnings for everything else. It would truly be a great thing if someone could chase down and at least @nowarn
them if they are legit or necessary for bincompat. Then at least we can avoid adding more unused stuff.
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.
Seems that Scala 3.0.2 ignores any @nowarn
annotations, unfortunately. I found it out while working on #4083.
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.
Yes, that's right. But @nowarn
is supported in Scala 3.1 and I believe we should bump for that and other reasons. See:
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 won't be getting any "unused" warnings anymore after this change, is that correct?
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.
That's right, no more unused warnings :(
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.
It's a good question. So IIUC, you mean enable all warnings, but disable fatal warnings?
The only problem is that there are so many unused warnings they drown out everything else maybe.
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.
Yes, I also hate seeing warning:) This is why I attempted to make some relief in #4083. And I would be glad to continue working on that.
Answering your question – yes, I think seeing warnings is still better than suppressing them completely.
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.
Yes, now that I came face-to-face with the problem myself, I truly appreciate your heroic efforts in #4083 :)
Ok, that's fair. I'll restore all the default compiler flags from sbt-typelevel, but disable fatal warnings.
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.
Btw: there're also loads of deprecation warnings in some modules (which mostly don't make any real sense). And there're so many of them that it is quite easy to miss something really important.
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.
Right, that's exactly my concern. The only way to be sure you don't miss warnings, is to make them fatal. But that means we have to disable the warnings that we can't solve today.
lazy val unidocs = project | ||
.enablePlugins(TypelevelUnidocPlugin) | ||
.settings( | ||
name := "cats-docs", | ||
ScalaUnidoc / unidoc / unidocProjectFilter := inProjects(kernel.jvm, | ||
core.jvm, | ||
free.jvm, | ||
algebra.jvm, | ||
alleycatsCore.jvm | ||
), | ||
scalacOptions ~= { _.filterNot(_.startsWith("-W")) }, // weird nsc bug | ||
ScalaUnidoc / unidoc / scalacOptions ++= Seq("-groups", "-diagrams") | ||
) | ||
.settings(commonSettings) |
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.
This introduces a new API-docs only cats-docs
module that lets us publish unidocs to Sonatype/Maven. Then they can be browsed at javadoc.io.
Example:
https://www.javadoc.io/doc/org.http4s/http4s-docs_2.13/0.23.11/org/http4s/index.html
// TODO: remove these filters after MiMa 1.1.0 is released with improved support for Scala 3 | ||
ThisBuild / mimaBinaryIssueFilters ++= { |
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.
@dwijnand has very kindly fixed this in lightbend-labs/mima#683 :)
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.
Sorry I've not cut a release yet - life things shuffled my priorities the last 3 weeks.
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.
No worries, just means we'll appreciate it even more when it arrives! :)
Yep, rolled out 16k lines of headers 😬 Also applied Sergey's suggestion to keep all the warnings enabled, non-fatally. Merged in my separate site PR. Oh, I need to set a proper start year for the headers ... |
915 files changed versus ~140 before that.. Seems that Git has lost tracks of small files after they received the headers.. What are the key files for the review? I doubt if I can make all 915 :) |
|
Any thoughts on landing this one? 🙏 I need to update this PR to account for the just-merged #4166 ... |
Agree. I would vote to hold off other merges until we get this landed. Regarding the merging of this one.... I found it tremendously difficult to reason about the safety of the changes made. They look good to me, but I realize that I cannot follow everything here. So... What about scheduling an "RC" release after merging this PR? E.g. "2.8.0-RC1" or something. Just to let everyone (who would like to participate) test the result artifacts for potential BinCompat issues first. Would it make sense? |
Sure, I'm 👍 to publishing Ms, RCs, etc. :) actually, as soon as this merges it should immediately publish a snapshot if all goes well.
Depends on what you want to test :) if you want to test the fix for #4062, for sure, that makes sense. If you want to test whether the build will prevent the publishing of binary-breaking changes, then we'd have to try and introduce one first :) because besides the fix for #4062 this doesn't really change any code. I.e. everything should be 100% binary compatible, because it already was. |
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 think we should go ahead and merge it.
@armanbilge now when I run
Just to clarify: is it supposed to run this way? |
@satorg hmm, no, that's a bug 😕 try setting |
Unfortunately, changing values of either |
Sorry, I meant we should permanently add it to |
No worries. I can go ahead and file a PR for that. |
@armanbilge although it is merged now... But seems I missed it while was reviewing. Line 26 in fe40bc2
It sets the default Scala version to 2.12, which is different from how it was before (2.13). |
@satorg I agree, 2.13 makes more sense. I changed it to 2.12 in ce873ff because mdoc wasn't working in 2.13, since the sbt-typelevel-site plugin uses the default Scala for building/deploying documentation. In principle, we can hack around this in the build ... but just like fatal warnings, best option is to fix the root problem. I.e. get the docs building on Scala 2.13. We can make an issue for it and a contributor may be interested to work on it. |
Ah I see – it was for the reason. |
Closes #4143. Fixes #4062. Fixes #4149.
Things seem to be working locally. But the battle with CI is just beginning.
Note this PR doesn't deal with the documentation/site at all (they are currently not being checked in CI). I'll prepare that in a follow-up for easier review, although they should probably merge together.