Make SbtBuildTool respect crossScalaVersions #5637
Conversation
|
I am having issues running tests on my mac, would one of the maintainers be able to trigger a test run to see that this trivial change doesn't break any existing functionality? If everything passes fine I will continue working on writing a test (plus anything else that is needed) |
| @@ -44,7 +44,7 @@ case class SbtBuildTool( | |||
| override def bloopInstallArgs(workspace: AbsolutePath): List[String] = { | |||
| val bloopInstallArgs = List[String]( | |||
| "-Dbloop.export-jar-classifiers=sources", | |||
| "bloopInstall", | |||
| "+bloopInstall", | |||
There was a problem hiding this comment.
One problem would be that configuration would be overridden. We need to have scala version added to the name of the bloop json file.
I wouldn't make it as a default also, in some projects this might produce a large number of targets, so ideally this would be opt in.
There was a problem hiding this comment.
One problem would be that configuration would be overridden. We need to have scala version added to the name of the bloop json file.
Can you point me to where the logic is for picking up the various bloop.json files?
I wouldn't make it as a default also, in some projects this might produce a large number of targets, so ideally this would be opt in.
Sure, I would say first lets get the feature working. I think it might be possible to do improvements in this regard, i.e. it seems that various scala 2 versions can share the same build target and its only with scala 3 where its problematic, in which case I don't think the "explosion" in build targets is that big and maybe can be justified as default behaviour.
There was a problem hiding this comment.
Sorry for not getting back sooner, I was off on vacation and just got back to the issue.
We could potentially change the name to include scala version here:
either by adding another setting, which we would set while running +bloopInstall or maybe its possible to detect that case (if we are running with a +)
We can't really just change the name general unless we make sure that the old filenames are replaced.
Are you still interested in pursuing this?
There was a problem hiding this comment.
Sorry for not getting back sooner, I was off on vacation and just got back to the issue.
Likewise, sorry for not getting back to the comment I was at a wedding.
We could potentially change the name to include scala version here:
either by adding another setting, which we would set while running +bloopInstall or maybe its possible to detect that case (if we are running with a +)
We can't really just change the name general unless we make sure that the old filenames are replaced.
Thanks I will look into this
Are you still interested in pursuing this?
I am but I have a lot on my plate right now so I will probably get to it close to the end of the year, feel free to pick it up sooner if it makes sense to do so. One thing that I had in my mind is creating a new sbt command in sbt-bloop along the lines of bloopInstallAllRelevantVersions (feel free to bikeshed name) which will generate the bloop json for only the necessary Scala versions rather than just blindly for all Scala versions in crossScalaVersions. This is based on the presumption (which I have noticed, correct me if I am wrong) that at least for Scala 2, bloop/metals seems to work with all Scala 2 with just a single generated bloop json for Scala 2 so the idea behind the bloopInstallAllRelevantVersions command is that it will find the "best" Scala 2 version and generate the bloop json from that and then if you happen to also have Scala 3 it will generate a bloop json of that.
The idea is that this is a compromise between not generating bloop json for all scala versions and only for the Scala version set in scalaVersion, i.e. we would have at most 2 generated bloop.json (if you have a cross Scala 2/Scala 3 project although I am not factoring in Scala.js/scala-native, not sure how this works).
Let me know what you think.
There was a problem hiding this comment.
I think we could make it a bit smarter I think, though that might be complex. We could potentially generate json files for anything that has custom sources. So if it differs from the default, we would generate an additional json file. This way if a project only cross compiles the same sources we would have a single json file.
Though I imagine not everyone would want to have all targets always since it makes the full compilation take much longer. This doesn't also solve the issue for sbt BSP (though I imagine it should be able to control it from the command line even if it's not possible now).
Maybe we should three import modes:
- simple import the same as currently
- import all possible targets
- import all that contain non standard sources (optionally)
Alternatively instead of the last mode, we could allow turning off some modules in the doctor, which would be saved between the sessions. Or we could allow to import a different Scala Version with a manual input (as a workaround of the current default mode).
Currently when using metals via sbt it only creates the bloop definition file for the configured
scalaVersion. This means for projects that support multiplescalaVersions, in particular Scala 2 vs Scala 3 metals fails to work on the scala versions not configured byscalaVersion, giving a"No build target found"From what I have noticed is that the problem is only between Scala 2 and Scala 3 and not specific versions within Scala 2 (although I may be half wrong here as I would suspect due to stdlib differences between different Scala 2 versions it can have an impact here as well).
References: scalameta/metals-feature-requests#13