It Is fine to split your package into multiple sub-packages? And when should i do that?

When i was writing Kotlin or Typescript, my way of organizing a project was to divide it into sub folders where each sub folder defines its own module, and the job of the main module was just to re-exports the sub-modules. With Julia i know dividing a project into submodules is not exactly the julian way of doing things, is preferable to have only one module per package that includes multiple files. So, in my search to how better structure my projects i looked a packages like Makie, which has multiple sub-packages in the same repository. This kept me thinking that maybe dividing a package into multiple sub-packages may be a good idea, especially if the package has more than 15 files to include, and i know some functionalities can be grouped together and isolated from the rest. But my project is not as massive as Makie is, and i’m not sure if the sub-packages will end up big enough to justify them being a whole package.

So, my questions are:

  1. It is fine to split up your package into multiple sub-packages?
  2. It is fine to create a whole new package even if it is small at the beginning?
  3. It is fine if the main package just reexports the sub-packages?

The only reason to use sub packages is if people need to use them separately, e.g. to reduce compile time or unnecessary dependencies. It has overheads for development and Pkg.jl resolution that you shouldn’t pay without a reason.

Just for organisation, you can use modules rather than sub packages. Then it is fairly easy to refactor into separate packages if and when you need that.

But this is also not really required, fifteen files does seem like youre getting close to a tipping point to needing some structure, but I’ve had more than that without modules with no problems. There are less name-space clashes in julia because we reuse common base methods for a lot of funcitonality.

3 Likes