Julia relative imports, issue #4600, exactly how "not that difficult" is it?

DevJac · February 12, 2020, 6:24am

I’ve reached the point in my Julia journey where I’m seeing the limitations of include for assembling lots of modules into a project. It seems https://github.com/JuliaLang/julia/issues/4600 is the answer, but progress seems slow. Fortunately, @StefanKarpinski claims that it “shouldn’t be that difficult” and tags “help wanted”.

I want to help. I’m willing to put a few dozen hours into this feature during the next few weeks.

But how “not that difficult” is this issue? I’ve never worked on a project as large as Julia, and I can read some C, but have never written much of it? Can I help?

Tamas_Papp · February 12, 2020, 6:45am

I would recommend that you discuss in the original issue (I think it is OK to ask for help there, too).

The first thing I would check is if the proposed solution is still the recommended approach — it was more than 2 years ago.

I think most of this code is in base/loading.jl.

(I have moved your topic from Jobs, since I am assuming that you are willing to do this unpaid )

StefanKarpinski · February 12, 2020, 4:16pm

Last I looked at this, you need to modify the logic in

github.com

JuliaLang/julia/blob/master/src/module.c

// This file is a part of Julia. License is MIT: https://julialang.org/license

/*
  modules and top-level bindings
*/
#include "julia.h"
#include "julia_internal.h"
#include "julia_assert.h"

#ifdef __cplusplus
extern "C" {
#endif

JL_DLLEXPORT jl_module_t *jl_new_module_(jl_sym_t *name, uint8_t default_names)
{
    jl_task_t *ct = jl_current_task;
    const jl_uuid_t uuid_zero = {0, 0};
    jl_module_t *m = (jl_module_t*)jl_gc_alloc(ct->ptls, sizeof(jl_module_t),
                                               jl_module_type);
    assert(jl_is_symbol(name));

This file has been truncated. show original

to implement the behavior described in #4600.

stevengj · February 12, 2020, 4:17pm

Note that a technique for importing submodules from relative paths is currently

include(“path/to/MyModule.jl”)
import .MyModule # note .

Syntactic sugar for this might be nice but is not essential.

StefanKarpinski · February 12, 2020, 5:14pm

I think the most important contribution of implementing #4600 for this would be standardizing the file paths for files that define modules, since you can’t use the relative import without include call unless the paths match the module names. Aside from that, it doesn’t really make much of a practical difference—it’s literally just about saving you from typing that include line. I guess there’s cases where you might avoid having to think about which code that uses a relative submodule should include it (the first user), which is nice too.

DevJac · February 14, 2020, 6:21pm

Thanks for the replies.

I ended up solving the problem that was motivating me to work on this issue by modifying the LOAD_PATH. Now that I know includes are not the only way to organize a project, things aren’t nearly as bad as they seemed.

I added my project’s src directory to the LOAD_PATH, and then renamed some source files to match the name of their module. I think what I have now is called a “package directory”?

You talked about “standardizing the file paths for files that define modules”. Isn’t this what package directories do already? As far as I understand, #4600 would give me nothing that package directories do not already give me, except maybe relative imports could work without having to modify the LOAD_PATH?