Tips directory structure/LOAD_PATH
If you are starting such a large project (approx 20 modules), I suggest taking advantage of LOAD_PATH
instead of using pkg> add
or pkg> dev
. It is the easiest way to learning Julia development, and you can migrate to the pkg>
system when your are closer to publishing your solution to Julia’s General
registry (if you so desire).
Quick dev: 1 file per “software module”:
If you are migrating from Python, you might want to try the 1 file per “software module” solution:
my_package_repo
├── Module1.jl
├── Module2.jl
├── Module3.jl
...
├── ModuleN.jl
NOTE:
- I myself have never tried this “single file” module solution, but it is supposed to work.
- Don’t forget that the code from each Modulei.jl file must be encased in a
module Modulei
…end
block.
Add my_package_repo
to LOAD_PATH
You just have to make sure you first add:
push!(LOAD_PATH, "/path/to/my_package_repo")
You can set this variable in your ~/.julia/config/startup.jl
or set it from a shell environment variable:
If you do this, you should no longer use pkg> add Module1
. LOAD_PATH
takes care of making it available to your project.
Typical package directory structure:
But to be able to migrate to the pkg>
system more smoothly, I suggest you use the proper Julia directory structure from the start. Among other benefits, this structure (optionally) includes test/
folders for ci tests, and more clearly groups together package solutions that are split across multiple files.
my_package_repo
├── Module1
│ ├── Project.toml (optional)
│ ├── src
│ │ ├── Module1.jl
│ │ ├── Module1SubFile1.jl
│ │ └── Module1SubFile2.jl
│ └── test
│ └── runtests.jl
├── Module2
│ └src
│ └── Module2.jl
├── Module3
│ └src
│ └── Module3.jl
...
└── ModuleN
└src
└── ModuleN.jl
Again, I re-iterate:
- Don’t forget that the code from each Modulei.jl file must be encased in a
module Modulei
…end
block.