Should our package export an init! function?

Not init!, no, but there’s CommonSolve.jl and it defines what it means to init and solve! a model. If your use jives with their definitions, then you can depend on that very lightweight package and share the same function.


In general, you have multiple options as a package author:

  • You can choose to not export names that you expect will collide with packages that are commonly used alongside yours; potentially just making them public instead.
  • You can decide to depend upon the other package and explicitly choose to use their function
  • You can decide to coordinate with other packages and come up with a lightweight “common” or “base” or “interface” package that you can all depend upon and whose functions you share. That’s what CommonSolve.jl is doing.
  • You can simply decide it’s the user’s problem and happily export away

If you run into this issue when using two packages A and B, you also have lots of options:

  • You can import A and then always explicitly use A.init! and A.solve and A.whatever at all call sites
  • You can explicitly resolve some names upfront with using A: A, init!, and, others… and you can automatically generate those lists of used names with ExplicitImports.jl
  • You can also rename as you import — using A: init! as initialize! vs. using B: init! as put_in_it! or whatever makes sense
  • You can manually “fixup” using A, B by defining what you want init! to mean with const init! = A.init!.
  • Or you can just using A, B and just always make sure you explicitly say A.init! or B.init!. Julia will happily remind you if you forget.

Even if the method signatures are entirely non-overlapping between two distinct init! methods, Julia cannot and will not automatically merge them together.

11 Likes