# Current best practises on dealing with optional dependencies

**URL:** <https://discourse.julialang.org/t/current-best-practises-on-dealing-with-optional-dependencies/78015>\
**Category:** General Usage\
**Tags:** package, dependencies\
**Created:** [March 17, 2022, 9:11am UTC](https://discourse.julialang.org/t/current-best-practises-on-dealing-with-optional-dependencies/78015 "2022-03-17T09:11:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Luapulu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/luapulu/32/17669_2.png) [@Luapulu](https://discourse.julialang.org/u/Luapulu)\
**Post date:** [March 17, 2022, 9:11am UTC](https://discourse.julialang.org/t/current-best-practises-on-dealing-with-optional-dependencies/78015/1 "2022-03-17T09:11:15Z")

</div>

Say I’ve written up a package to compute `Foo` and now I’d like to add support to write and read `Foo` to HDF5 or to plot `Foo`. May be I’d like to plug a DifferentialEquations.jl solution into `Foo`. What is the current recommended way to do deal with integration with large packages?

Should I just live with having giant dependencies in my package to add functionality only some users will sometimes need?

Or do I make little glue packages like FooHDF5.jl, FooDiffEq.jl and FooPlots.jl which glue my package and these large dependencies together? This doesn’t force large dependencies on the package but still allows for full functionality. It comes at the cost of a proliferation of glue packages though.

Or do I use Requires in my package? If so don’t I still need to have the dependency in my Project.toml even if the code doesn’t get loaded, right? And I still have the increased CI workload of having to test the integration with these large packages everytime I make any change to my code, even if it doesn’t affect integration.

---

<div class="post-metadata">

**Author:** ![Luapulu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/luapulu/32/17669_2.png) [@Luapulu](https://discourse.julialang.org/u/Luapulu)\
**Post date:** [March 20, 2022, 2:11pm UTC](https://discourse.julialang.org/t/current-best-practises-on-dealing-with-optional-dependencies/78015/2 "2022-03-20T14:11:21Z")

</div>

@ChrisRackauckas would you mind sharing your thoughts on this?

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [March 20, 2022, 4:20pm UTC](https://discourse.julialang.org/t/current-best-practises-on-dealing-with-optional-dependencies/78015/3 "2022-03-20T16:20:09Z")

</div>

> [@Luapulu](#):
>
> Or do I make little glue packages like FooHDF5.jl, FooDiffEq.jl and FooPlots.jl which glue my package and these large dependencies together? This doesn’t force large dependencies on the package but still allows for full functionality. It comes at the cost of a proliferation of glue packages though.

Most of these have small Base packages you’re supposed to hook into so you avoid the dependencies. RecipesBase.jl, SciMLBase.jl, etc.

---

<div class="post-metadata">

**Author:** ![Luapulu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/luapulu/32/17669_2.png) [@Luapulu](https://discourse.julialang.org/u/Luapulu)\
**Post date:** [March 20, 2022, 7:38pm UTC](https://discourse.julialang.org/t/current-best-practises-on-dealing-with-optional-dependencies/78015/4 "2022-03-20T19:38:13Z")

</div>

So it seems the recommendation would be to split up large packages so that the basic interface can be extended without loading the whole thing. So, once a package gets large enough with enough dependencies it should probably split up into a BaseFoo.jl and SpecificFoo.jl for specific features.

Small package developers then shouldn’t need to worry about dealing with requires and such since extending the basic interface of large packages shouldn’t incur much of a cost.