I’m not sure I understand why you don’t want the MyApp code and the MyLib code to live in the same project/package? (For example, the code defining MyLib could be put into some subdirectory of src, and maybe put in a separate submodule if you want to guarantee it doesn’t depend on outer MyApp code)
I’m not sure I understand why you don’t want the MyApp code and the MyLib code to live in the same project/package?
What I have done so far is to use include("...") to spread my code among many files. Perhaps because of my experience with C++ templates, I trend to view large include graphs as something to be wary of, particularly as the application grows larger. There seems to have been some lively discussion about using relative imports – but some proposals amount to something like include + using – which feels like it makes pre-compilation an impossibility. Is there a way to use submodules without using include or guarantee pre-compilation?
From what I have read, one package per project per repo is a valid way to factorize development of larger applications. But I haven’t warmed to this as it seems like overkill and increases coordination cost between components; for packages used in one code base, git branches suffice for my needs. There may be a way forward by manipulating LOAD_PATH outside of the Pkg REPL; if so I would like to hear if/how others do it in v1.6+.
Yes, if Lib has long precompilation times, it is a good reason to factor it out in a separate package, in order to ensure that it will be pre-compiled independently. (To be clear, if Lib was a submodule of MyApp, it would still get precompiled, but the precompilation would happen again each time MyApp changes).
Please don’t manipulate LOAD_PATH yourself, and use Pkg.dev instead (giving it a relative path to your library).
Note that if you want to get the full benefits of having Lib be a fully fledged package, it should have its own Project.toml, that list its own dependencies.