I have a question that was discussed a few years ago here and here, but those discussions seem to be outdated as none of the solutions given there work for me.
Say I have a package MyPackage with a module MyPackage.jl that provides the main functionality and some modules OptionalModule1, OptionalModule2, etc. that provide optional functionality. I want the user to be able to access these optional modules with something like
using MyPackage
using OptionalModule2
or perhaps
using MyPackage
using MyPackage.OptionalModule2
While the optional modules could be made submodules of the main module, I don’t want the overhead of loading a bunch of optional modules the user may not want.
Is there a way to do this?
Of course, I do that all the time in FinEtools. I include the modules in the top module.
1 Like
But including modules causes them to be immediately loaded, whether the user wants to use them or not. I was asking if there is a way to make the modules available for loading if and when the user wants them, so that modules not requested by the user don’t incur any needless overhead.
I see. But selective optimization levels may be of help here, perhaps?
On second thought: would it make sense to split up the package then? Perhaps what is optional is distinct enough from the basic functionality that it warrants its own package?
It could be that the overhead isn’t as big of a concern as I fear. If the submodules support precompiling, then in principle the overhead of parsing and compiling would only be incurred once. But IIUC they would still take up memory.
Making them separate packages is valid suggestion, but in my case the optional modules really only make sense in the context of the main package.
Yes, I made the same decision. But FinEtools used to be a lot bigger. So while it has “optional” modules that are still part of the basic package but need to be usinged separately, most of the functionality has been separated out into individual packages.
Thanks. The precursor of that topic is actually very relevant. It addresses a number of distinct issues, but the behavior proposed by @tim.holy and @kristoffer.carlsson in #1874 is very similar to what I am looking for.
1 Like