Can the package name be reverted to `doobie`?

[kevin-lee]

Can the package name be reverted to doobie?

I understand the reason for changing the organization from org.tpolecat to org.typelevel, but I don't think changing the package name is necessary. The package name doesn't have to match the organization. For example, Cats uses cats instead of org.typelevel.cats.

Changing the package name from doobie to org.typelevel.doobie has caused compatibility issues and requires users to add the extra org.typelevel prefix, which I don't see any benefit in.

Could you please consider reverting only the package name, while keeping the organization as org.typelevel?

[armanbilge]

The package name doesn't have to match the organization.

Technically, that is true. We have several examples like this. However, it is not the reason for the change.

Changing the package name from doobie to org.typelevel.doobie has caused compatibility issues and requires users to add the extra org.typelevel prefix, which I don't see any benefit in.

Actually, the reason for this change is to prevent compatibility issues. Because the artifact coordinates changed from org.tpolecat to org.typelevel, sbt (and other Scala tooling) will no longer automatically evict an older version of Doobie if it ends up in an application's dependencies alongside Doobie 1.x.

So, the only way to prevent users from encountering non-deterministic linking issues at runtime due to inadvertently having multiple incompatible versions of Doobie on the classpath is to change the package name.

[kevin-lee]

@armanbilge Thank you for the explanation. I understand the intention now.

Unfortunately, this means I need to update over 50 repositories. Moreover, some libraries I use still depend on the older version, so I won’t be able to use the latest doobie. If the package name had stayed the same, I could have simply added exclude or excludeAll to exclude all older doobie versions from org.tpolecat.

So I’m still not sure which solution is more practical. 🤔

[jatcwang]

Hi @kevin-lee, sorry for the trouble. As Arman explained we're trying to surface any incompatibilities at compile time instead of causing issues at run time.

In case you haven't seen it, there's a scalafix rule which you can use to help you migrate your project . Let me know if you run into any issues with the scalafix rule.
This is a semantic rule which means it is accurate in its modifications but requires compilation. If you have issues with running the scalafix rule, let me know.

Alternatively, I should be able to whip up a syntax-only rule which is inaccurate but can be applied without needing to enable semanticdb etc for the build - let me know if this will help.

[kevin-lee]

@jatcwang @armanbilge Thank you. At first, I thought we would have a problem either way, but Doobie’s solution made it more difficult to solve. However, on second thought, I have to agree that compile-time failure is way better than runtime failure.

Yeah, I already saw that Scalafix rule in the release notes, and I really appreciate that this easy migration option has been provided. Thank you!