Typelevel migration changes

[DavidGregory084]

• The project is now published under the org.typelevel group ID
• The project and its GitHub Actions workflow are now built with sbt-typelevel

[armanbilge]

My heart says thumbs up, but we need to think carefully about how to manage the circular dependency this will eventually create between sbt-typelevel and sbt-tpolecat which will be problematic when we want to build the plugins for sbt 2.0. Here's one example workaround for that:

• Exclude sbt-github-actions from the sbt-spiewak plugin and link the plugin to the sources in this repository sbt/sbt-github-actions#78

I'm very 👍 to changing publishing and all that goes with it, but also I think there's no rush (basically before sbt-typelevel 0.5.0 would be good). So if there's any other breaking changes hopefully they can accumulate as well?

Fortunately steward will lend a hand with it! :) see e.g.

• Add artifact migration for sbt-git scala-steward-org/scala-steward#2545

[armanbilge]

Actually, not really. You should change a publishing org without changing a package name, because otherwise eviction doesn't work*. But as soon as you change the package name, it's no longer bincompatible.

* sadly any org/package change for sbt-plugins is a mess, recently went through this in:

• Change package to com.github.sbt.git? sbt/sbt-git#216

[DavidGregory084]

Hmm I didn't even think about sbt eviction, that's even more difficult to resolve.

[armanbilge]

One workaround for the cycle is that sbt-typelevel should just temporarily drop sbt-tpolecat when it starts compiling for sbt 2.0. It will be extremely annoying (my flags!) but fortunately it's not critical to publishing a milestone or something which should be enough for sbt-tpolecat to publish its own update, at which point we are golden.

[DavidGregory084]

Fortunately steward will lend a hand with it! :) see e.g.

* [scala-steward-org/scala-steward#2545](https://github.com/scala-steward-org/scala-steward/pull/2545)

Yep I've actually already raised scala-steward-org/scala-steward#2587

[armanbilge]

Btw, the cycle will also be a problem if we want to dog-food sbt-tpolecat to itself and make binary breaking changes that impact sbt-typelevel. We can always publish sbt-tpolecat using sbt-typelevel and an older release of sbt-tpolecat. But dog-fooding the current sbt-tpolecat into its own build might not play nice with the sbt-tpolecat that sbt-typelevel was expecting.

[DavidGregory084]

Perhaps it would make more sense to make sbt-tpolecat depend on sbt-typelevel-ci-release instead and avoid the cycle?

[armanbilge]

Right, that would mitigate the dog-food binary-breaking problem I described above.

Unfortunately, there would still be shenanigans in some situations. Even though sbt-typelevel-ci-release doesn't directly depend on sbt-tpolecat, the build used to publish sbt-typelevel-ci-release would depend on sbt-tpolecat.

Really, the only solution I think is (virtual) monorepo :( which is plenty undesirable for its own reasons.

[armanbilge]

Actually, if it's possible to build/publish sbt 2.0 plugins from sbt 1.0, then that would help solve the problem too I think. Then in theory sbt-tpolecat could update to sbt 2.0 without needing sbt-typelevel to do anything.

For example, sbt-typelevel has a circular dependency on Cats(-Effect) through Laika, which use the plugin. But because the classpaths remain independent it works out okay.

[DavidGregory084]

Hmm if sbt 1.x -> 2.x follows the same pattern as 0.13.x -> 1.x then I don't know if that would be possible, but we could certainly register an interest in that kind of migration path now while folks are still thinking about what sbt 2.x will be?

[DavidGregory084]

The migration from 0.13.x -> 1.x was that 1.x could cross-build for 0.13.x, but not vice-versa. This meant that folks could still back-publish plugins for 0.13.x once they had been ported to 1.x but not forward-publish for the new version.

[armanbilge]

Right, it might be a big ask for this niche case of circular dependencies :(

Anyway, we can think about this more. Adding a cycle for now (esp. only to sbt-typelevel-ci-release) is fine I guess, but one day we will have to do something about it.

[DavidGregory084]

FWIW, it might be that cross-building for 2.x would work perfectly already - the reason that we couldn't forward publish on 0.13.x is that 1.x added the sbt cross building functionality (crossScalaVersions and crossSbtVersions and friends) so it simply wasn't possible before that!

[DavidGregory084]

@armanbilge I'm going to sit on this one for 0.4.x, but add a notice in all of the release notes that this will be the last minor release series under io.github.davidgregory084.

[DavidGregory084]

Closing this for now - it will need reworking after #88 and we haven't decided what to do for 0.5 yet