Experiment replacing Scalaz by Cats dependency

[julien-truffaut]

• replace scalaz by cats in core
• create a scalaz-support module and move all optics for scalaz classes there

[julien-truffaut]

see https://github.com/julien-truffaut/Monocle/tree/cats

next step: release a snapshot

[julien-truffaut]

1.3.0-cats-SNAPSHOT published for 2.10 and 2.11

[julien-truffaut]

just to clarify, monocle will only move to cats once it reaches a stable version (probably 1.0).

[ngbinh]

👍

[yilinwei]

Is this only on github or has it been published to sonatype/bintray?

[stew]

@yilinwei I found it here: https://oss.sonatype.org/content/repositories/snapshots/com/github/julien-truffaut/monocle-core_2.11/1.3.0-cats-SNAPSHOT/

[yilinwei]

@stew Must be something dodgy with my own sbt resolvers then. Thanks!

EDIT

I found the issue pretty quickly and should have noticed it from the file output earlier. I had forgotten to add the sonatype resolvers to one of the subprojects which was dependent on another subproject which was dependent on monocle. sbt then took the resolvers for the subproject without sonatype to look for cats when I was compiling the root.

[japgolly]

I think it would be better to have Monocle not depend on either Cats or Scalaz and have modules for both available. I think in the past the reliance on Applicative was a problem but it would be trivial to create a Monocle Applicative trait and then have the scalaz + cats modules provide conversions from {scalaz,cats}.Applicative to monocle.Applicative.

[japgolly]

Btw, it's less of a deal for a user of A to have Monocle introduce an otherwise-unused B to the classpath (where (A,B)∈{ (cats,scalaz), (scalaz,cats) }) in JVM-land than it is in Scala.JS-land. Under Scala.JS it's a Big Deal because it significantly increases the output JS size which website visitors must all download, and the traffic must be paid for by host and clients.

[julien-truffaut]

I understand dependencies are more of an issue in js world. However, scalaz or cats are central to a library like Monocle e.g. Applicative or Traverse for Traversal, Monoid for Fold, Functor for Iso, Lens and so on. On top of that, I don't think it makes sense for all libraries to define their own basic typeclasses with scalaz and cats impl, it is maintenance hell and makes the code more difficult to understand.

I am more than open to discuss if / when shall we transition to cats but I believe we need one of the two dependency.

[lvicentesanchez]

@julien-truffaut what do you think of initiatives like shims?

[julien-truffaut]

@lvicentesanchez I didn't know about it but after a quick look it seems less than complete. Also it doesn't solve the problem of Xor vs \/

[kenbot]

Does the newly right-biased Either in 2.12 solve the / vs Xor problem?

[julien-truffaut]

Recently, we discussed going to support both scalaz and cats probably via different branches. The cats branch should use Either but we can maintain our usage of \/ for the scalaz branch. It will probably be less disturbing for users.

[julien-truffaut]

closed in favour of #419