Cats: Propose stop publishing `cats` bundle

[benhutchison]

(Channeling @travisbrown) I propose getting rid of the cats artifact. The only real role it plays is bundling core, free, and the laws / tests packages, and it's just as easy to explain how and when users need each of those individual pieces.

1181 is example of confusion caused

[benhutchison]

Im actually having second thoughts myself..

@ceedubs clarified the thinking behind the cats artifact: "I think that there's a natural progression of people starting with that and potentially later adding free or laws as needed for their use-case. I think that @non liked the idea of recommending the "batteries included" version and letting people trim off pieces once they were ready for production usage. "

The batteries included idea resonates with me if/when cats grows lots of modules; it worked for Haskell. And, remembering how annoying it seemed as a Scalaz newbie when things I was using suddenly disappeared and I didn't have context on why, Im think there's value in keeping existing cats deps working for users.

What about instead of removing it I write a paragraph for the readme explaining when to use cats vs cats-core?

[travisbrown]

I don't really like the "here's how you do this thing (but remember not to ever _actually_ do this thing, because weird stuff will happen)" model of pedagogy. :smile:

In particular I'm not sure there's ever a good reason to have a non-test dependency on cats-laws or cats-tests, and this necessarily makes them a non-test dependency. Apart from them there's just cats-free, and if you get a compiler error for import cats.free._ that's arguably a lot easier to track down than a bunch of unexpected stuff showing up in your builds.

[benhutchison]

Agree on removing cats-{laws/test} from cats bundle.

Still see value in "batteries included" though. Right now there's only cats-free but more could be added, eg there's some talk of alleycats coming into cats. If cats is "everything you might need for runtime use", then there isn't such a clear need to trim it later.

[adelbertc]

I would like to see a cats that includes all modules except test-related things, and then perhaps a cats-testing or similar for laws and tests.

[benhutchison]

I started a PR to try close this, that'd remove test-related things from cats, but got stuck on some SBT voodoo in build.sbt.

If anyone knows too much about Ivy Configurations and could educate & unblock me, I'll be very grateful and send a PR to close this issue in return ;)

[jeantil]

This issue can still be reproduced, simply create an empty project, follow the readme by adding
libraryDependencies += "org.typelevel" %% "cats" % "0.9.0" and run the dependency graph plugin to see that scalacheck is included in the compile classpath.

The sbt voodoo is partially explained in the documentation
and partially explained in a discussion on the sbt-dev mailing linst

Regarding the line you mentionned in gitter, I think it effectively translates to

• cats%compile-internal depending on bench%compile-internal
• cats%test-internal depending on bench%test

maybe @non who seems to have written this in the first place (https://github.com/typelevel/cats/commit/09b4b86b3b8e48c64786de35548499635dc83fd4) can enlighten us further.

[ghost]

As I might well have been the originator of the "voodoo", I can confirm that there is no "voodoo" at all.

Well, almost none.

The undocumented feature:

• https://groups.google.com/forum/#!topic/sbt-dev/XBcv-GlegRM
• https://groups.google.com/forum/#!topic/simple-build-tool/7E6k_gLJ5hw

eg:

An sbt-specific configuration is "compile-internal". This is the one actually used for compilation (it pulls in "compile", "provided", and "optional"), but it isn't published.

[ghost]

And seeing that this is now in 1.0.0-MF, it might be worth incorporating https://github.com/typelevel/cats/issues/472 here as well, and hammer out a solution once and for all.

However, before a solution is done (that I would be happy to help out with, if needed) it's probably worth getting a consensus on the desired library structures and repositories.

[ghost]

To add to the mix re removing the cats bundle (that I can see both sides of the argument) :

Removing the cats bundle will potentially break a bunch of builds, but better to do now than later. But another option would be to rename it such that a "batteries includes" option still exists, but named such that it is obviously _not_ meant for production , eg to cats-trial, cats-quick-start, cats-all etc

Proposed questions:

1) cats bundle:
a) Keep as-is
b) Keep as-is but minus test libs
c) Rename as-is
d) Rename as-is but minus test libs
e) Remove
2) alleycats:
a) separate repo
b) cats submodule
3) Add a complete "testing" lib, that pulls in all laws and testing libs.
a) Yes
b) No

There might be other options. But based on this, my opinion (IMHO, naturally)

I think folk in general are more "sbt happy" than ,say, a year or so ago. So provided we give clear documentation similar to circe Quick start (N.B. circe seems to work fine with this method)

1) e (remove cats bundle and go on holiday just before the release)
2) b (move alley cats)
3) Yes, call it cats-testkit

[kailuowang]

Remove from project 1.0.0-MF as it's consolidated into #1682.

[ceedubs]

@benhutchison @kailuowang after #1682 we are probably good to close this one out, right?