sbt-plugin datasource should always overridePackageName with _2.12_1.0 suffix

[MPV]

How are you running Renovate?

A Mend.io-hosted app

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

No response

Please tell us more about your question or problem

As a follow-up / separate issue related to:

• datasource/sbt-plugin doesn't support registries that doesn't allow dir listing #33637

...where we were able to workaround that temporarily by setting this for sbt-plugin:

{
  "matchDatasources": ["sbt-plugin"],
  "overrideDatasource": "sbt-package"
}

Now we are still having problems to look up SBT plugins, since they are requested as myplugin whereas instead they are published with the package name being myplug_2.12_1.0, as this is the requirement when building SBT plugins:

1. You cannot choose what Scala runtime is the SBT built against, you need to use the version compatible with the SBT you have.
   -- https://stackoverflow.com/questions/47186130/scala-sbt-version-of-plugin/47186360#47186360

2. sbt plugins must be compiled with Scala 2.12.x that sbt itself is compiled in. By NOT specifying scalaVersion, sbt will default to the Scala version suited for a plugin.
   -- https://www.scala-sbt.org/1.x/docs/Plugins.html#Creating+an+auto+plugin

3. sbt 1.0 uses Scala 2.12 for build definitions and plugins.
   -- https://github.com/sbt/sbt/releases/tag/v1.0.0

---

This is possible to also override and solve, by also doing:
overridePackageName: "{{ packageName }}_2.12_1.0"
i.e:

{
  "matchDatasources": ["sbt-plugin"],
  "overrideDatasource": "sbt-package",
  "overridePackageName": "{{ packageName }}_2.12_1.0"
}

...to get SBT plugins to work via GAR / Google Artifact Registry (until a fix is in place).

That said, we suggest that the sbt-plugin datasource should start hardcoding a suffix of _2.12_1.0 into the packageName, to make sure it's explicitly finding the dependencies by the right name (and not by accident as when its parsing HTML and discovers it).

Logs (if relevant)

Logs (after overrides, working)

DEBUG: Overriding datasource from sbt-plugin to sbt-package for org.xerial.sbt:sbt-pack
DEBUG: Overriding packageName from org.xerial.sbt:sbt-pack to {{ packageName }}_2.12_1.0 for org.xerial.sbt:sbt-pack
[...]
DEBUG: Sbt: no versions discovered for org.xerial.sbt:sbt-pack_2.12_1.0 listing organization root package folder, fallback to maven datasource for version discovery
[...]
DEBUG: Found 3 new releases for org.xerial.sbt:sbt-pack_2.12_1.0 in repository https://europe-maven.pkg.dev/myproject/myrepo/
          {
            "datasource": "sbt-plugin",
            "depName": "org.xerial.sbt:sbt-pack",
            "packageName": "org.xerial.sbt:sbt-pack",
            "currentValue": "0.20",
            "depType": "plugin",
            "registryUrls": [
              "https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases",
              "https://repo.maven.apache.org/maven2"
            ],
            "updates": [],
            "versioning": "ivy",
            "warnings": [],
            "sourceUrl": "https://github.com/xerial/sbt-pack",
            "registryUrl": "https://europe-maven.pkg.dev/myproject/myrepo",
            "packageScope": "org.xerial.sbt",
            "currentVersion": "0.20",
            "fixedVersion": "0.20"
          }

[MPV]

A potential drawback would be that hardcoding to _2.12_1.0 would effectively lock Renovate to supporting SBT plugins only for SBT 1.x and not 0.13.x (as mentioned here), so ideas are welcome on how the solution for Renovate should look to support sbt plugins published (with the name suffix) for those versions, when/if the maven-metadata.xml support is added for the sbt-plugin datasource (which would make it support GAR / Google Artifact Registry, GitLab etc).

[gaeljw]

Also SBT 2.x is coming and will use Scala 3 I believe.

[MPV]

Yes, so there are at most 3 variants to cover for resolving the name suffix of SBT plugins (?):

• SBT 0.13.x = Scala 2.10
• SBT 1.x = Scala 2.13
• SBT 2.x = Scala 3 (docs, discussions)

Should it be the scala manager or the sbt-plugin datasource that has the logic of constructing the sbt plugin packageName from the above rules (depending on what sbt version is detected in the repo)? Or when adding maven-metadata.xml support for the sbt-plugin datasource how would we prefer Renovate makes it find the variants using the right packageName given this particular versioning limitation with SBT plugins?