This worked perfectly on v0.6 but no longer works on v0.7 and I can’t understand why.
Say I have a package, Foo with the following structure:
Foo/src/Foo.jl
Foo/src/Bar.jl
In Foo.jl I have
push!(LOAD_PATH, @__DIR__)
using Bar
However, Bar can not be found. 
The typical way to do this would be
Foo.jl
include("Bar.jl")
using Bar
instead of messing with LOAD_PATH. Is there a reason for not doing that?
Thanks.
Not really. I guess it just wasn’t clear to me.
Is it recommended against using LOAD_PATH? Why? What’s the purpose of LOAD_PATH if not to be used for such scenarios? And more importantly, why doesn’t it work in 0.7 anymore if the folder is added to LOAD_PATH?
Sorry, I’m just extremely confused about the way the dependencies are supposed to be handled now.
@kristoffer.carlsson Is LOAD_PATH going to work again as it did in v0.6? I tried switching to include(...) + using ... but there are so many modules which are cross-referenced, it’s so redundant and just plain ugly. In v0.6 I’d just setup the LOAD_PATH and everything would just load, which was super neat and elegant.
All I can say is that LOAD_PATH is not really supposed to be used like that. LOAD_PATH is a “higher level” concept meant for users to control which packages they can load but the package itself shouldn’t depend on it.
Using submodules in a package is fine but the files of the submodules should be included, as e.g. Documenter does:
Thank you @kristoffer.carlsson - that’s very helpful. I started refactoring per your feedback and it’s all working very well! 
Just as a side-note, from my perspective, it’s a shame that LOAD_PATH doesn’t work for this anymore. Genie has a pretty large code base and since starting it, with Julia v0.4, I’ve spent a ridiculous amount of time organizing and optimizing the project’s structure and managing the dependencies (which are both inner package submodules and in-app, developer-generated MVC files).
The result of these multiple iterations was setting up the LOAD_PATH and using Module. Employing LOAD_PATH was by far the most productive approach. Without it, one has to include 10-20 (30?) submodules, by hand – instead of adding the folder and having Julia pick them up from there. It’s the kind of work that computers are much better at. Less to type, less to manage, neat and tidy.
Anyway, just my 2 cents, in case other developers feel the same, I’d like to see this back…
You can always programmatically just loop through a folder with submodules and include everything.
If the packages are truly different packages then they should depend on each other with REQUIRE files and all that.
Yup, thought about the loop myself – problem is load order though?
Oh yes, that’s a totally different issue which has been bugging me for months now. Between Genie and SearchLight, for example, I have a number of modules which are used in both packages. Like a Configuration module. I wouldn’t want to publish a package which does nothing on its own, just so it can be shared by other packages. So, for now, I’ve resorted to having a Configuration submodule in each package, copy-pasted, yuck!
I share your regret because I seem to have connected my modules
in a similar way as you. With the current behavior of LoadPath,
a very clear and systematic method of the workflow has been
broken.
The “why” is not answered by the fact that this freedom of
design was not initially intended, it was there and seemingly
had no disadvantages. I still hope that this will be acknowledged
as a bug.
In my setup the following workaround seems to work: add the line
(@DIR) \notin LOAD_PATH && push!(LOAD_PATH, (@DIR))
as the first line of each file.
Clearly a very ugly thing.