Dependency policy - should we avoid dependencies or embrace them?

Indeed, that’s why I am using the phrase “developer target” to mean “low dependency packages for users to get the functionality of a specific ecosystem”. For example, to plug into DiffEq you only need DiffEqBase which doesn’t really have anything other than the problem definitions (so no dependencies on ForwardDiff, NLsolve, etc. either). You can use that to define and solve problems if the user passes an appropriate algorithm. If you want to place a default algorithm, then you need to depend on that solver package. Nobody should be depending on DifferentialEquations.jl because, from what I can tell, there’s nobody solving ODEs, SDEs, DDEs, DAEs, discrete stochastic equations, doing sensitivity analysis, etc. all together, so it’s quite a big dependency for no reason (whereas DiffEqBase is small and OrdinaryDiffEq is large in its own right but still manageable). For this reason most packages just depend on DiffEqBase, OrdinaryDiffEq, or Sundials.

However, users don’t need to care about developer targets. If you want to solve a differential equation, it’s pretty clear you do using DifferentialEquations. If you don’t know what to do, you know what documentation to look at:

http://docs.juliadiffeq.org/latest/

The fact that the metapackage isn’t actually required to do anything isn’t something users should have to deal with. And re-writing 20 similar documentations with similar tutorials is much worse than just explaining the overarching philosophy once and showing the special parts related to each problem.

Developers want the Unix “do one thing” setup. Users want SciKitLearn. They are different and both should be catered to if we want things to be easy and scalable.

8 Likes