Location of config.exs post compile (calling from Erlang)

Questions / Help
1

I have a basic question about using config.exs in a mixed Erlang/Elixir environment.

I am running an existing Erlang node that includes my Elixir dependencies, by literally adding them to the -pa switch:
-pa ../game_database/_build/dev/lib/*/ebin -pa ../game_database/_build/dev/consolidated

This way I can directly include Elixir applications in an existing Erlang codebase (I use application:ensure_all_started to recursively include the applcations – including this Elixir one).

which seems to work until I start relying on variables created and maintained in config/config.exs. I’m running the build and trying to see where these variables might end up in the /ebin and can’t seem to make any headway.

These config variables are definitely not being included, as I can see a stacktrace when I try to start the application with them.

In Erlang-world the configs are stored in various *.config files that can be referenced from sys.config, but I don’t seem to see any of this as the result of a mix build.

Is it true to say that all my /lib .exs files might end up in the /ebin of the app directory of __build but that /config .exs files don’t? If this is the case, how do I make sure they are “compiled” to Erlang-compliant .config files?

thanks,
daniel

1 Like
2

Interesting.

I think I have found my own answer, but will post this here on the forum for posterity’s sake.

I was operating under the assumption (and thus trying to prove) that running a mix build would produce a binary artifact that would contractually fulfill the role of an Erlang application – and could thus be included directly into the startup script of an existing Erlang node.

The results of the build process certainly seem to indicate this as both the deps of my mix.exs and my lib/ file are generated with an application compliant directory structure (including .app files)

.└── dev ├── consolidated └── lib ├── connection │ └── ebin ├── db_connection │ └── ebin ├── decimal │ └── ebin ├── ecto │ └── ebin ├── game_database │ ├── ebin │ └── priv -> ../../../../priv ├── poolboy │ └── ebin -> ../../../../deps/poolboy/ebin └── postgrex └── ebin

More context, I have yet to produce a formal release either using relx for my Erlang application and have been using application:ensure_all_started as a release-lite. As I mentioned above, by adding

-pa ../game_database/_build/dev/lib/*/ebin -pa ../game_database/_build/dev/consolidated

to my run_erl script, I have been able to reference the application directly.

It turns out, however, that the DSL of Mix.Config does NOT make its way into this binary artifact (this contractual bundle, if you will). I found an excellent blog that talked about this. Apparently this is well known, and the correct way to approach this is to elevate yourself from the contractual bundle of an application into a formal release, and thus tools like exrm and more appropriately conform handle this process. (this makes sense in retrospect, since sys.config and their ilk are files that reltools help build).

This blog post talks about this, and was a perfect answer to my question:

In continuing with my release-lite strategy, I also plan on using his light-weight script that transforms a config/config.exs directly into the Erlang terms that can be included in a sys.config file.

2 Likes