Note: escripts do not support projects and dependencies that need to store or read artifacts from the priv directory.
So I tried setting it up to specify an external copy of exec-port using the portexe override option. This still failed because the default(portexe) was still getting evaluated (repeatedly) despite having an override passed in and the error generated by the wildcarded search for exec-port was un-handled. (Example trace below.)
=INFO REPORT==== 9-Nov-2016::15:44:53 ===
application: logger
exited: stopped
type: temporary
Could not start application erlexec: :exec_app.start(:normal, []) returned an error: an exception was raised:
* (FunctionClauseError) no function clause matching in :filelib.wildcard/2
(stdlib) filelib.erl:58: :filelib.wildcard('/exec-port', {:error, :bad_name})
(erlexec) /sdd/jenkins_builds/jobs/cannery-builder/workspace/deps/erlexec/src/exec.erl:550: :exec.default/1
(erlexec) /sdd/jenkins_builds/jobs/cannery-builder/workspace/deps/erlexec/src/exec.erl:543: :exec.default/0
(erlexec) /sdd/jenkins_builds/jobs/cannery-builder/workspace/deps/erlexec/src/exec_app.erl:62: :exec_app.init/1
(stdlib) supervisor.erl:294: :supervisor.init/1
(stdlib) gen_server.erl:328: :gen_server.init_it/6
(stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3
I have a patch I will submit as a pull request shortly that seems to allow the override of the portexe without undue re-evaluation of default(portexe) and has that function simply issue a warning message in the error case. The net of this is that by overriding the portexe location, erlexec will be usable from an escript. The existing tests still pass under my patched version, but I was unsure how to create a unit test that would validate the escript functionality (though it does work fine in my actual use case).
In trying to use erlexec from an Elixir escript to pipe input to an external executable, I found the following in the mix escript.build docs (http://elixir-lang.org/docs/master/mix/Mix.Tasks.Escript.Build.html):
So I tried setting it up to specify an external copy of exec-port using the
portexeoverride option. This still failed because thedefault(portexe)was still getting evaluated (repeatedly) despite having an override passed in and the error generated by the wildcarded search forexec-portwas un-handled. (Example trace below.)I have a patch I will submit as a pull request shortly that seems to allow the override of the
portexewithout undue re-evaluation ofdefault(portexe)and has that function simply issue a warning message in the error case. The net of this is that by overriding theportexelocation, erlexec will be usable from an escript. The existing tests still pass under my patched version, but I was unsure how to create a unit test that would validate the escript functionality (though it does work fine in my actual use case).