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

Initial work for scoverage 2.0 #1547

Closed
wants to merge 2 commits into from
Closed

Conversation

ckipp01
Copy link
Collaborator

@ckipp01 ckipp01 commented Nov 6, 2021

scoverage 2.x makes a few changes to the structure of the scoverage project, including the artifacts, and also will allow for Scala 3 support once scala/scala3#13880 gets merged. I wasn't super familiar with how mill was using it, so this was just me learning a bit and updating some of the things I saw. However, it introduces a few questions that I'd love to get your thoughts on.

This is a breaking change that won't easily allow for users to use 1.x anymore. Are you ok with that? Once scoverage bumps to 2.x it will be pretty much impossible to support both 1.x and 2.x for integrations since the structure is quite different, even some of the package names, method signatures etc. In the sbt plugin once I officially bump I'll error out if someone manually tries to use 1.x in the 2.x series of the plugin. What are you thoughts on something like that in Mill?

I'll ask the other question in the parts of the code to make them clearer.

I'll leave this as a draft for now but will iterate on it since there is a few things we'll need to update if you're ok with the 2.x approach listed above.

  • Add some messages to make it clear to the user that once on 2.x they need to use 2.x
  • Add in the logic to determine if the user is using Scala 2 or 3. If 3, then just set the -coverage flag and the datadir
  • Add some stuff to the tests to cover both the Scala 2 and Scala 3 usecase

@@ -573,7 +573,7 @@ object contrib extends MillModule {
override def compileIvyDeps = T{
Agg(
// compile-time only, need to provide the correct scoverage version runtime
Deps.scalacScoveragePlugin,
Deps.scalacScoverageReporter,
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I didn't fully understand this. Is this only being used to pull the version? I switched this to the reporter just to test it and it worked as well, but probably won't leave it as the reporter.

Copy link
Member

@lefou lefou Nov 6, 2021

Choose a reason for hiding this comment

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

The contrib.scoverage.worker is loaded by the contrib.scoverage module in an isolated classloader. The contrib.scoverage.api module is shared between both. So we can load the scoverage jars only when needed and isolated from other mill plugins. Technically, this allows us to use different scoverage versions in the same build. As Scoverage 2.x has an incompatible API, we need to create a new worker module working with Scoverage 2.x. We also do this in other plugin, e.g. contrib.playlib.

@lefou
Copy link
Member

lefou commented Nov 6, 2021

This is a breaking change that won't easily allow for users to use 1.x anymore. Are you ok with that? Once scoverage bumps to 2.x it will be pretty much impossible to support both 1.x and 2.x for integrations since the structure is quite different, even some of the package names, method signatures etc. In the sbt plugin once I officially bump I'll error out if someone manually tries to use 1.x in the 2.x series of the plugin. What are you thoughts on something like that in Mill?

There is a major difference between the sbt plugin for Scoverage and this mill plugin. The sbt plugin is external to sbt and users can probably use the older versions supporting scoverage 1.x for a very long time. As our scoverage plugin is developed in-tree, we in general only support compatibility to the exact same mill version. (This is different for plugins developed outside of the tree.)

So my question is, do we loose something with Scoverage 2.x? E.g. support for older Scala versions? If that should be the case (which I assume to be true), I'd say we should try a bit harder to keep support for Scoverage 1.x in the plugin. We already use a worker to load and use the scoverage API, so it should be pretty easy to have some switch for the dependencies depending on the actual used version and implement a new worker for Scoverage 2.x.

@@ -573,7 +573,7 @@ object contrib extends MillModule {
override def compileIvyDeps = T{
Agg(
// compile-time only, need to provide the correct scoverage version runtime
Deps.scalacScoveragePlugin,
Deps.scalacScoverageReporter,
Copy link
Member

@lefou lefou Nov 6, 2021

Choose a reason for hiding this comment

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

The contrib.scoverage.worker is loaded by the contrib.scoverage module in an isolated classloader. The contrib.scoverage.api module is shared between both. So we can load the scoverage jars only when needed and isolated from other mill plugins. Technically, this allows us to use different scoverage versions in the same build. As Scoverage 2.x has an incompatible API, we need to create a new worker module working with Scoverage 2.x. We also do this in other plugin, e.g. contrib.playlib.

Comment on lines +8 to +13
def report(
reportType: ReportType,
sources: Seq[os.Path],
dataDirs: Seq[os.Path],
sourceRoot: os.Path
)(implicit
Copy link
Member

Choose a reason for hiding this comment

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

As the worker API is shared between all worker implementations, we need to keep/support the sourceRoot parameter, in case we decide to keep the Scoverage 1.x worker.

@ckipp01
Copy link
Collaborator Author

ckipp01 commented Nov 10, 2021

So my question is, do we loose something with Scoverage 2.x? E.g. support for older Scala versions?

Yea, this is exactly the case. In the 2.x series we'll no longer publish for 2.11.

@lefou
Copy link
Member

lefou commented Nov 10, 2021

@ckipp01 Let me know if you need further guidance in creating a new worker module for Scoverage 2.x. Or just ping me in our Gitter channel.

@ckipp01
Copy link
Collaborator Author

ckipp01 commented Nov 10, 2021

@ckipp01 Let me know if you need further guidance in creating a new worker module for Scoverage 2.x. Or just ping me in our Gitter channel.

Sounds good. It'll probably be a bit before I get around to it. Once I get the green light on the direction in the pr to Dotty I'll probably swing back around to this, but I'll let you know.

@kierendavies
Copy link
Contributor

@ckipp01 Are you planning to get back to this? I may be interested in picking it up.

@ckipp01
Copy link
Collaborator Author

ckipp01 commented Jun 28, 2022

@ckipp01 Are you planning to get back to this? I may be interested in picking it up.

Hey @kierendavies! I was planning on it, but no idea if it'd be soon or not. Seeing that scoverage 2.0.0 is release, by all means pick this up if you'd like. Feel free to ping me to review the scoverage parts or anything and I'll be happy to give some insight. If you do pick it up, just let me know so we don't duplicate work.

@lefou
Copy link
Member

lefou commented Aug 22, 2022

Is anybody working on this? @ckipp01 or @kierendavies ?

@ckipp01
Copy link
Collaborator Author

ckipp01 commented Aug 22, 2022

Is anybody working on this? @ckipp01 or @kierendavies ?

Not me. I don't really have any plans in the short-term to get back to this.

@lefou
Copy link
Member

lefou commented Aug 29, 2022

As there is nobody currently working on this and we decided to keep the old worker but also as there are merge conflicts in this PR, I decided to re-start this work in a new branch and pull request:

I heavily used this PR to identify the required changes. Thank you Chris (@ckipp01) for creating this PR!

Closing this PR as it is superseded by #2010.

@lefou lefou closed this Aug 29, 2022
@lefou lefou mentioned this pull request Aug 29, 2022
2 tasks
@ckipp01 ckipp01 deleted the coverage-2 branch August 29, 2022 09:08
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