[erlang-questions] what is point of having a .erlang file?
Mon Jan 21 23:17:29 CET 2019
On Mon, Jan 21, 2019 at 01:54:03PM -0800, Sam Overdorf wrote:
> I have customers and I want the same configuration for all of them so
> ".erlang" sounds like a good option for me.
> The problems is "erl" will run the ".erlang" file but "escript" does
> not run the ".erlang" file.
> I prefer to use "escript" because the consistent handling of arguments
> passed in.
> What is the solution?
I would suggest to use releases for your non-escript packages, and
use either escript's ability to package a full runtime system in with
the escript, or use it's ability to pass command-line options in the
second or third line of the script. To quote the man page on that:
On the third line (or second line depending on the presence of
the Emacs directive), arguments can be specified to the emula‐
tor, for example:
%%! -smp enable -sname factorial -mnesia debug verbose
> Sam Overdorf
> On Mon, Jan 21, 2019 at 7:35 AM Jesper Louis Andersen
> <jesper.louis.andersen@REDACTED> wrote:
> > On Mon, Jan 21, 2019 at 1:53 AM Sam Overdorf <soverdor@REDACTED> wrote:
> >> What is the point of having a".erlang" file if I have to run
> >> "c:erlangrc()" in all of my programs.
> > Usually, it is to have a set of development changes and configurations to the Erlang system. There might be some helper functionality you wrote for yourself, or tend to use in projects you want to check out. Rather than having to add them to each project, it is somewhat easier to configure them from a central point. This is also, roughly, its historical usage to my knowledge.
> > However, it is a doubly edged sword, insofar it also means that the software you run has local configuration and setup. If more than one developer works on the same set of software, the local configuration can mean the software doesn't run without the .erlangrc specific configuration. To a large extend, the focus on standard tooling such as Continuous Integration/Continuous Deployment seek to alleviate this. An even more modern approach is to always build everything the same way scratch such that the software is built in a reproducible way with idempotence as well.
> > My experience is that the more these (admittedly functional programming-like) ways of handling software builds are adapted, the easier it gets to work on software.
> erlang-questions mailing list
Hugo Mills | Gort! Klaatu barada nikto!
hugo@REDACTED carfax.org.uk |
PGP: E2AB1DE4 | The Day the Earth Stood Still
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the erlang-questions