Reducing coursier dependencies
See original GitHub issueThis issue is going to be highly controversial and may not even be considered due to the conflict of some of the design aims of coursier, essentially the issue is about removing dependencies which are either very large (scalaz) or create circular dependencies with libraries that may want to use coursier (ammonite-terminal, @lihaoyi is considering making ammonite use coursier)
If coursier’s aims are to be included in tools like SBT/ammonite (and others) by default, the dependencies need to be made as small as possible. Scalaz unfortunately, due to its monolithic design, weighs in at around 10mb.
There are obviously replacements for Scalaz (the other extreme would be just using the stdlib, which has Future
), but this obviously means that the core of coursier isn’t going to be completely “pure” (from a pure functional programming POV), i.e.
The cache module handles caching of the metadata and artifacts themselves, and is less so pure than the core module, in the sense that it happily does IO as a side-effect (always wrapped in Task, and naturally favoring immutability for all that’s kept in memory).
Other solutions can include using cats instead of Scalaz (cats core is currently much smaller, weighing at 2.7mb currently). Either that, or using an internal solution to replace the areas that Scalaz is being used for (i.e. Task)
Also using Future instead of Task can possibly provide performance improvements since a lot of high performance HTTP libraries (dispatch with netty or akka-http) are backed by Future’s
Issue Analytics
- State:
- Created 8 years ago
- Reactions:4
- Comments:15 (6 by maintainers)
Top GitHub Comments
coursier
1.1.x
(only released via milestones) doesn’t depend on scalaz anymore. The coursier and coursier-cache modules should basically only depend on scala-library and scala-xml.@leonardehrenfried I’ll handle that issue. For the core module, I’ll likely use SHIMs for
Monad
,EitherT
, maybeNondeterminism
, with the bare minimum methods (I tried some time ago, it seemed to work fine…).Then maybe a type class in cache abstracting over
Task
, and, if possible, aFuture
-backed implementation of it. And cats-effect and scalaz-concurrent modules with cats / scalaz implementations for it too.