Managing larger project in Julia

Hi,

Coming from the MATLAB background where a large project can be handled pretty easily by calling out all the other functions, which are written in separate .m files, into a Main.m file (the name Main is arbitrary) and then executing just the Main.m file. I am wondering on these lines what is the best way of handling such a large project in Julia?

I think you’re looking for the modules functionality (and specifically the export, using and import keywords). Look it up here.

2 Likes

You can divide the functions in files as you want, you have not to follow the typical division in MATLAB, unless you like it :wink:.

You can include functions defined in another function “otherfile.jl” simple using:

include("firstfile.jl")
include("otherfile.jl")

It is typical to divide the functions in several files, not exactly one file for function, and a file that include all implemented functions using include.

4 Likes

I haven’t used MATLAB since I think 2013b, but I’d say that managing larger projects is one of the areas where Julia really shines in comparison.

As @dmolina says, the key difference is that you don’t have to divide your code into loads of separate .m files, but can rather organise it in a way that groups functionality that belongs together into different .jl files.

For larger projects it often makes sense to also organise your work as a package - see the documentation here: https://julialang.github.io/Pkg.jl/v1/creating-packages/. This gives you benefits in terms of reproducibility (as you’ll have a Manifest.toml file that records the exact versions of all dependencies of your work) and nudges you towards writing tests for the functions in your codebase (if you use something like https://invenia.github.io/PkgTemplates.jl/stable/user/ you get test infrastructure and CI set up as well).

3 Likes

To be precise, in order to get the reproducibility benefit you need to use project environments, see here: https://docs.julialang.org/en/v1/manual/code-loading/#Environments-1

In fact, packages don’t usually come with the Manifest file

1 Like

Agreed, there is a step that I suppose can be seen as a in between just a throwaway script and a package, which is a project with its own environment.

I’m not sure why you think packages don’t come with a Manifest file? As is explained in the Pkg.jl docs here if you ] generate a package and then ] add some other package to your package, the dependencies will get added to the Manifest.toml. Or are you referring to the fact that usually public packages don’t come with a manifest, just the Project.toml for direct dependencies?

1 Like

Yes, sorry, that’s exactly what I meant: packages are not distributed with a Manifest (but you can definitely make one)

1 Like