Closed LukaJCB closed 5 years ago
I think it makes sense to have separate modules when we have separate dependencies. For these cases, we don't have any additional dependency.
I'm -1 on complicating the build for users just to separate these things for a reason I don't understand.
I think the cats-free situation is a mistake and a needless complication for our users. I hope we won't repeat it.
Just to clarify, you'd just put these in cats.data
@johnynek?
yessir
Agree. There's an engineering benefit to layering but I don't think we're there yet.
I still vote for a separate repo which gives it independent release cycles. Cats' BC requirements make it particularly rigid for trying new things.
We don’t have to have the same binary compatibility guarantees for all modules, but it is a pain to have to use a version number implying stability. Can we set different versions on different modules? You can usually do anything with sbt.
I guess I’m a bad scala person but I have a bunch of libraries I haven’t published solely because setting up sbt, cross build, travis and publishing usually hits several snags for each new project. I try and put in a few hours here and there to do the next one, but then I get frustrated with it all.
Setting up the build and doing publishing is not the fun part. The more “not fun part” we have the less energy we have left over to actually build the libraries.
@johnynek well, now dogs
become cats-collections
, at least we don't need to re-setup a repo again.
AFAIK, having different versions on different modules is tricky business. If you have the cats-collections module depending on the cats-core, you are still forced to release cats-core whenever you release cats-collections.
hurrah!
I don't mind doing the release all at once and I think our users will appreciate adding more collection types to cats-collections.
Right now we have
NonEmptyVector
andOneAnd
that aren't actually used inside core. There's also been some people that really wanted aNonEmptySet
andNonEmptyMap
as well as collections that don't use universal hashing, but the newHash
type class would also allow us different kinds of these. e.g.NonEmptySortedSet
andNonEmptyHashSet
So one idea to accommodate these and preserve modularity would be to create a new module inside the cats repo.