Question on Dependency-Related Best Practice for Packages

General Usage
, ,
1

Hello,

I don’t know which of the following is the better option or what should be done. I am hoping someone can help me decide.

I am developing PackageA. I have PackageB currently as a dependency of PackageA. Separately, there is PackageC which I do not have as an explicit dependency (is that the right terminology?) of PackageA but it is a dependency of PackageB.

Now I want to define a new function that uses methods from PackageC. I see I have two options.

  1. Add PackageC as a dependency of PackageA
  2. Within PackageA, include using PackageB.PackageC

I’m not sure which I should do.

2

Most of the time you want to use option 1, especially if you are not the author of B, because then B could drop its C dependency every moment without notice.

I could imagine using option 2 only if B is some sort of wrapper package (or a jll package) around C (eg GLMakie.jl always depends on Makie.jl), because then C is guaranteed to be always available. But I guess option 1 would also be ok then.

2 Likes
3

It’s definitely option 1.
Because then you get to impose your own semver constraints on PackageC.
Which you want to do incase its API changes, and PackageB upgrades to use the new version but you can’t.
That way semver will protect PackageA (and it’s users) from breaking.

The fact that option 2 works is kinda a coincidence and not a feature.

1 Like
4

It’s usually called a “direct dependency”. The terminology goes like this:

┌──────────────┐       ┌────────────┐       ┌───────────────┐
│              │       │            │       │               │
│    Package   ├──────►│   Direct   ├──────►│   Indirect    │
│              │       │            │       │               │
└──────────────┘       └────────────┘       └───────────────┘
                        \                                  /
                         \─────────Dependencies───────────/
1 Like
5

I’m developing my own package so I feel like I should know what semvar means…

6

“semver” = “semantic versioning” refers to having your version numbers mean something in particular (ie the difference between 1.0.0 and 1.0.1 or 1.1.0). See package docs for more info.