Add C/C++ diff: scope, modules, packages.

[ma-laforge]

Some of this information would be well suited for a more general (non-c-specific) section.

But from my observations on Discourse:
C/C++ users are particularly confused with the import/using vs include concepts.

[ma-laforge]

Thanks.

[ma-laforge]

Help: Correction needed?

Sorry. I think I misunderstood something:
-->https://docs.julialang.org/en/v1/base/constants/#Base.LOAD_PATH

Excerpt from docs for context:

---

LOAD_PATH

An array of paths for using and import statements to consider as project environments or package directories when loading code. It is populated based on the JULIA_LOAD_PATH environment variable if set; otherwise it defaults to ["@", "@v#.#", "@stdlib"]. Entries starting with @ have special meanings:

• @ refers to the "current active environment", the initial value of which is initially determined by the JULIA_PROJECT environment variable or the --project command-line option.

---

My issue.

My PR said the following:

• To develop a "conventional" application/project in Julia, you can initialize its root directory as a "Project Environment", and house application-specific code/packages there. This provides good control over project dependencies, and future reproducibility.

Though I had not tried it before a few days ago, I thought that was the point of having @ in JULIA_LOAD_PATH. That way, all the submodules of your project could be bundled as subdirectory of your "project environment":

• However, when I tried putting submodules under the @ directory, julia did not find them.
• I then explicitly tried to add the hardcoded absolute path to the project environment in JULIA_LOAD_PATH, and julia still would not load said modules.

It is almost like julia doesn't want us to place our packages under the environment path.

Question

Am I mistaken here?

[StefanKarpinski]

The @ entry has to be a project, it cannot be a directory with packages in it, it has to be a project with a project file add such. If you want to load packages from a directory, you can put, e.g. . in the load path.

[ma-laforge]

Oh. I understand now that I looked into:

Base.load_path_expand("@somelib") #show what an entry in LOAD_PATH means
Base.load_path() #show everything in LOAD_PATH

LOAD_PATH entries either represent environment paths (locations of Project.toml) - or paths where project directories will be loaded by Julia (mutually exclusive).

[ma-laforge]

I suppose this is is probably the best way we could create "conventional" applications in Julia, then:

Sample directory tree (root: a "generated" project)

MyApplication
├── startup.jl
├── Project.toml
├── src
|   ├── MyApplication.jl
|   └── additionalcode1.jl
└── lib
    ├── AppSpecificModule1
    |   └── src
    |       ├── AppSpecificModule1.jl
    |       └── additionalcode1.jl
    └── AppSpecificModule2
        └── src
            ├── AppSpecificModule2.jl
            └── additionalcode1.jl

MyApplication/startup.jl:

using Pkg

#Make sure we have a reproducible environment:
Pkg.activate(joinpath(@__DIR__)) #where startup.jl is located

#Setup LOAD_PATH environment
empty!(LOAD_PATH)
push!(LOAD_PATH, "@", "@stdlib", joinpath(@__DIR__, "lib"))
#NOTE:
# - Don't add: "@v#.#". Don't want user config to modify environment.
# - Now has `MyApplication/lib` to store application-specific code

# Start application
#-------------------------------------------------------------------------------
using MyApplication
MyApplication.run() #User-defined

Command to launch your "conventional" application:

julia --load "MyApplication/startup.jl"

[ma-laforge]

Check failing:
On my last commit, I re-merged into the master branch because I thought it might have been the cause of the failures.

It now looks like it had nothing to do with me.

Should I do a rebase or revert my commits something?
I know some people don't like these merge commits in their history.

[StefanKarpinski]

Would be nice if someone with C++ expertise reviewed this and merged it if it seems good.

[vtjnash]

some minor tweaks

[ma-laforge]

I'm ok with all of your suggestions @vtjnash.
Am I expected to click on "Commit suggestion"? (Never done this before).

[vtjnash]

Yeah, you can do "add suggestion to batch" to all of them in the "files changed" view to easily accept all of them as-written, or copy them locally individually and push the result. But I can also just accept all of them for you and then tag for merging once CI finishes.