johnhungerford

ZIO-like dependency injection using implicit resolution

Daniel Ciocîrlan recently published a video showcasing a dependency-injection (DI) approach developed by Martin Odersky that uses Scala's implicit resolution to wire dependencies automatically. (See also his reddit post.)

The basic pattern for defining services in Odersky's approach is as follows:

class Service(using Provider[(Dep1, Dep2, Dep3)])

laughedelic

Some of these practices might be based on wrong assumptions and I'm not aware of it, so I would appreciate any feedback.

1. avoiding some dependency conflicts:

   • install sbt-explicit-dependencies globally in your ~/.sbt/{0.13,1.0}/plugins/plugins.sbt
   • run undeclaredCompileDependencies and make the obvious missing dependencies explicit by adding them to libraryDependencies of each sub-project
   • (optionally) run unusedCompileDependencies and remove some obvious unused libraries. This has false positives, so ; reload; Test/compile after each change and ultimately run all tests to see that it didn't break anything
   • (optionally) add undeclaredCompileDependenciesTest to the CI pipeline, so that it will fail if you have some undeclared dependencies

2. keeping dependencies up to date and resolving conflicts:

   • install sbt-updates globally in your `~/.sbt/{0.13,1.0}/plugins/plugins.

joewalnes

This is a little trick to turn an executable Java jar.

It works on all unixy like systems including Linux, MacOS, Cygwin, and Windows Linux subsystem.

Step 1 Start with an all-in-one jar (with entry point and all deps within)

$ ls 
hello.jar

milessabin

scala> import shapeless._, syntax.singleton._, record._
import shapeless._
import syntax.singleton._
import record._

scala> object ->> {
     |   def unapply[K, V](f: FieldType[K, V])(implicit k: Witness.Aux[K]) = Option((k.value, f: V))
     | }
defined module $minus$greater$greater