1

My question is, how should my Erlang app reliably find a binary in the priv directory, not just in production; when installed properly, but during common test?

I realised today when I added a travis-ci configuration to an old Erlang app and pushed it to git-hub, that the process by which it works locally for me, is a little more fragile than I thought. The travis-ci build failed because it, not unreasonably, checked out my repo into a directory named after the repo, which is of the form erlang-APP. Locally my app is in a directory called APP-VSN though.

The result of this is that a call to code:lib_dir(APP) returns a correct result during the common test run locally, but if I rename my current directory to erlang-APP instead of APP-VSN (or just APP works too) my local build fails, just like it does for travis-ci, because code:lib_dir(APP) returns {error,bad_name}. The behaviour as though .. is added to the library path for rebar ct.

Renaming my github repo from erlang-APP to APP resolves the travis-ci build failure... but knowing the build tests only pass depending on the name of the directory the repo is checked out into doesn't sit right with me.

Michael
  • 3,639
  • 14
  • 29

1 Answers1

1

One way could be to use a soft link (either in the repo under version control, or created when initializing the tests), and make your Erlang code path go via the link. E.g., "./APP" -> ".", or "./lib/APP" -> "..".

RichardC
  • 10,412
  • 1
  • 23
  • 24
  • Right, this is a great suggestion, I should have thought about it really, I usually have `{lib_dirs, ["deps"]}.` in my `rebar.config` and as such linking `deps/APP -> ..` enables the build to work regardless of current directory name. Seems a bit of a funny thing to do but I don't find it objectionable and I can't think of any reason it could go bad. Could always add another directory to lib_dirs just for this purpose instead of deps if need be. – Michael Apr 02 '17 at 19:36
  • I have used a similar solution for the situation where a dependency (a git submodule) has a directory substructure with one or more app directories under it, so it cannot be checked out directly in the ERL_LIBS directory. In that case, I have attached the submodule to a separate directory on the side, and a soft link from lib/APP to subs/PACKAGE/.../APP. – RichardC Apr 03 '17 at 09:13
  • Yes, it's the adding self as a dependency that's a bit odd and arguably wrong... You can add to the code path explicitly via the `code` module, or by `erl -pa` and I guess `ebin` is so added by rebar, but actually, that hides the fact that in this case a code path is being added that is not derived from the library path, which in some cases like this, becomes a flaw. – Michael Apr 04 '17 at 09:21