It’s no secret that DifferentialEquations.jl is a big package, so sometimes you will not want to depend on it directly downstream. That’s not only okay but a good idea, only depend on what you need! However, I have seen this done incorrectly a bit, partially because it has changed over time, so I here is an overview of what you need to do. It’s somewhat modeled from this documentation page:
- If all your package needs to do is define some problem types, like
SteadyStateProblem, etc., then the dependency you want to use is SciMLBase. That is where the problem types live and it’s a very very small dependency. There’s no AD involved or anything, just some RecursiveArrayTools stuff used in the definition of the problem/solution interface.
- If your package is using a solver, say
Tsit5(), then you need to depend on that solver package. The ODE solvers page (and all solvers pages ODE Solvers · DifferentialEquations.jl) describe which package the solvers you’re using are coming from. You only need to depend on the solvers you’re supplying by your package. For example, if you have a
alg = Tsit5()keyword argument, you need to depend on OrdinaryDiffEq.jl so that instance is defined, but a user can change that keyword argument to use Sundials.jl without you requiring Sundials.jl.
- If your package is defining a solver, then you will want to require DiffEqBase.jl because that has all of the common tooling for norms, callbacks, etc. Because of this common tooling it takes on the common dependencies of the DiffEq solver stacks, like ForwardDiff. If you’re not defining a solver, you should either be depending on a solver or SciMLBase
- If you need the automatic algorithm choice, then you (at least currently) need to depend on DifferentialEquations.jl directly. However, you should really think about whether your package needs that. In most cases what people are actually looking for is the automatic stiffness detection algorithms, which are algorithms in OrdinaryDiffEq like
AutoVern7(Rodas4()). See ODE Solvers · DifferentialEquations.jl for more details.
- If your package is using a modeling tool, like ModelingToolkit.jl, then add those directly.
That will be the leanest version you can get and should improve load times, precompilation caching, etc.