When slurping files in the REPL, some times (include-lib ...) doesn't work

[odacoder]

I've noticed this in the kanin (LFE AMQP) library. For instance:

> (slurp "src/kanin.lfe")
src/kanin.lfe:10: error expanding (include-lib "kanin/include/amqp-client.lfe")
error

The work-around in the REPL is to do the following:

> (code:add_patha "../kanin")
true
> (slurp "src/kanin.lfe")
#(ok kanin)

I had thought that whether an ebin was present on a path in (code:get_path) or not, includes could still be found. Perhaps I mis-read the Erlang source. Perhaps naively, I am under the current belief that the issue is due to this. When adding lib paths in ERL_LIBS and with -pa options, an ebin is post-fixed in the code paths, and with these paths, the include is not found.

For instance, the list returned when calling (code:get_path) doesn't have ../kanin in it; it only has ../kanin/ebin. This path is essential for compiled code -- without it, compiled code can't find the includes. In the REPL, however, this doesn't seem to help. Only when I add the path manually, without the "ebin" appeneded, do I get a successful slurp in the REPL.

I'll try to hack something up in the make include that calls lfetool with -eval "code:add_patha(\"../kanin\").", but Ifetool may not support that ... I may need to submit a fix that lets lfetool support this.

Perhaps this is an issue with the LFE REPL? Maybe I should report an issue there, too ...

[rvirding]

I had thought I had replied to this but apparently I didn't.

There are a couple of issues here:

• When slurping a file in the REPL it does not search for the file itself down any path, you must give the explicitly give the directory containing the file, either relative or absolute.

• The include-lib in LFE works in exactly the same way as include_lib in Erlang: it uses the ebin ending directories in the code search path to find the directory to enter to find the file. So if you do an (include-lib "bert/include/george.lfe") it will try to find an .../bert/ebin directory in the path, if it finds one it will then try to find the sub-directory file bert/include/george.lfe. It what purposely done in this way to mirror the erlang functionality. Note: it will only consider directories in the path which explicitly end in /ebin so it will ignore "."; it can handle directories in the path with a name with a version extension, so it will find bert-1.4.7/include/george.lfe. For more info check out

  http://erlang.org/doc/man/code.html#lib_dir-1

If we want it to work this way is something we can discuss. Do we want slurp in the REPL to also be code path based when trying to find a file? This discussion could be moved to the LFE mailing list

https://groups.google.com/forum/#!forum/lisp-flavoured-erlang

Robert

[rvirding]

The latest test version of LFE in the lfe-dev branch now handles search paths properly. I will soon release this into the develop branch and then when it feels really safe into the master branch.