Allow build tools to supply bridge JARs themselves

[alexarchambault]

This change allows build tools to supply bridge JARs themselves, so that the Bloop server doesn't have to fetch them itself later on. This allows to fetch those JARs from non-standard repositories, that the Bloop server doesn't know about.

Going to open PRs against scalacenter/bloop and scala-cli/bloop-core for more context.

[ckipp01]

Thanks for the pr @alexarchambault! I'm probably missing a bit of context, but looking at https://github.com/VirtusLab/scala-cli/pull/1730 it's not 100% clear to me what the use-case is.

This change allows build tools to supply bridge JARs themselves, so that the Bloop server doesn't have to fetch them itself later on.

Can you give an example of why fetching them later on is an issue?

This allows to fetch those JARs from non-standard repositories

This isn't very common right? Especially for the bridge jars?

This would be a breaking change here, so trying to better understand the use-case.

[alexarchambault]

Can you give an example of why fetching them later on is an issue?

The test added in the second commit of https://github.com/VirtusLab/scala-cli/pull/1730 is one. We try to ensure that a published locally version of dotty can be used fine in Scala CLI. For reproducibility, and so that the test doesn't "leak", we use a custom repository rather than ~/.ivy2/local.

More generally, this raises the following question: in what cases should the Bloop server (really the server - not the CLI, that can fetch the server itself for example) fetch any artifact? Users already supply the compiler class path. For Scala 3, the bridge more or less comes along the compiler (it has the same version as the compiler, originates from the same organization, …). There's no reason for Bloop to fetch it itself.

[ckipp01]

in what cases should the Bloop server (really the server - not the CLI, that can fetch the server itself for example) fetch any artifact?

I think the correct answer would be, never. I don't really think it should fetch anything. I agree with you.

For Scala 3, the bridge more or less comes along the compiler (it has the same version as the compiler, originates from the same organization, …). There's no reason for Bloop to fetch it itself.

I guess what pops into my head is, is this easy for everything else using Bloop to do?

I'm not opposed to this change, but the compat question does come into mind. Following the discussion that happened the last time we introduced breaking changes I just want to be more careful. @tgodzik do you have thoughts on how we should be handling breaking changes now that we introduced mima?

[kpodsiad]

Any config-related change should also update config schema

[tgodzik]

in what cases should the Bloop server (really the server - not the CLI, that can fetch the server itself for example) fetch any artifact?

I think the correct answer would be, never. I don't really think it should fetch anything. I agree with you.

For Scala 3, the bridge more or less comes along the compiler (it has the same version as the compiler, originates from the same organization, …). There's no reason for Bloop to fetch it itself.

Coming back to it after a while, I think this is really useful for Scala 3, which no longer have separate artifacts, so indeed there is no need to fetch them separately. For Scala 2 it made sense as we needed to compile them outselves, but for Scala 3 no.

I guess what pops into my head is, is this easy for everything else using Bloop to do?

I'm not opposed to this change, but the compat question does come into mind. Following the discussion that happened the last time we introduced breaking changes I just want to be more careful. @tgodzik do you have thoughts on how we should be handling breaking changes now that we introduced mima?

It would be great to have a way to evolve the config in a binary compatible way, so essenatially we would need to drop the usage of case classes. We could do one incompatible change, switch to config 2.0.0 with a way to add new things. Would it makes sense to use https://github.com/alexarchambault/data-class for that @alexarchambault ?

[alexarchambault]

Would it makes sense to use https://github.com/alexarchambault/data-class for that?

It might… as soon as it gets Scala 3 support. That said, even if Scala 3 gets supported, macro annotations for it are still experimental, so IIUC, users should only be able to define data classes in an @experimental annotated object, like

@experimental
object Foo {
  @data class Something(…)
}

So it'd be a bit cumbersome to use here.

[ckipp01]

Now that Scala 2 will also ship with these Jars the same way that Scala 3 does, is this still worth pursuing?

[tgodzik]

Now that Scala 2 will also ship with these Jars the same way that Scala 3 does, is this still worth pursuing?

I think it's still a problem for the Scala 3 compiler, when you want to use the locally compiled bridge, which is not available in dependencies yet. So any place that puts a bridge in a non standard location (I can only think of the compiler though)