Different configs for dev / production?

[David Welton]

I asked this on the Erlang list:

http://erlang.org/pipermail/erlang-questions/2014-May/079310.html

The ideal thing would really be to have a common config file, with
perhaps some kind of if/else for small differences. Or auxiliary
files for dev and production that contain additional configuration for
those.

Thoughts?
--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

[Kai Janson]

Hi David,

I like the idea with conditional logic for different environments.
Maybe the easiest way to get there would be to have a tuple that points to a different section or a different config file.

{development, "development_settings.conf"}, %% on file system

or

{development, DevelopmentSettings} %%(which would be a section within the boss.config file)

and triggering this by a switch for the compiling process,

./init.sh --env development ; ./init.sh --env production

There is also a pull request on GitHub for simplifying boss.config

Best,
--Kai

Sent from my non-google-device

> --
> You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss...@googlegroups.com.
> Visit this group at http://groups.google.com/group/chicagoboss.
> To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CA%2Bb9R_tEZNxEYvBWEUjVGLY2N-fMM8eOQEHOEgVLBFyzXonRuQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Evgeny M]

At the moment I just use another boss.config file for production, named boss.config.rel - my build script copies it over development one into the build directory from which .deb, .rpm and .tar.gz packages are generated by the same script. 

It would be nice to have something like boss.config and boss.config.dev - .dev should be loaded automatically with init-dev.sh (or load boss.config if boss.config.dev does not exist), init.sh should load boss.config. Having just one file with ifs' would be impractical when the app is getting packaged into a package such as .deb - in this case boss.config file is usually marked as 'config file', this prevents blind overwriting of it by a package manager in case when user did any modifications to the old config file. When developer makes changes to this file (and developers do this often), even in developer 'if' branch, package manager sees this file as modified  (a new branch of this file) and will show an unnecessary prompt to the user - what to do with the changed config file. Imo having two separate config files would be fine and easier to implement.

пятница, 30 мая 2014 г., 15:09:14 UTC+4 пользователь David Welton написал:

[Jesse Gumm]

I'm torn on whether or not to use dev-specific config files onto have dynamically loaded config sections of a single config.

I wouldn't feel terribly comfortable doing *too* much hackery by way of precompiling config dynamically.

That said, having it explicitly load a boss-dev.config or something like that would probably be the simplest change to add prod/dev config splits.

--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

--

You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss...@googlegroups.com.
Visit this group at http://groups.google.com/group/chicagoboss.

To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/e47b2e94-d39b-4180-a441-544d591185ac%40googlegroups.com.

[Kai Janson]

Named environment boss.configs might be the easiest.  Easy to manage, too.

+ 1

Sent from my non-google-device

To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CAPTXyXeqawzQzSOq8Q1mhBAm15wV368BQk2sw6Tnhjt-jsW2ng%40mail.gmail.com.

[can2nac]

i use next approch for any number of envs:

- modifed CB/priv/rebar/boss_rebar.erl 

- run ./rebar boss c=compile

- add {use_config, CONFIG_FILE}, in your PROJECT/boss.config to use another env., example: {use_config, "boss.test.config"}, {use_config, "boss.test"}, {use_config, "boss.test-5.config"}, {use_config, "boss.test-5"},

used in prod and env modes only

in test modes the same approach remains

%%% When running tests, you may want to create a separate configuration file

%%% "boss.test.config" which, if present, will be read instead of boss.config.

[can2nac]

this can be done with additional rebar params, example, ./rebar boss c=start_dev_cmd config="boss.test-2.config"

you need to modify PROJECT/priv/rebar/boss_plugin.erl to make this works

[can2nac]

i have modified boss_plugin.erl and boss_rebar.erl so one can use

 ./rebar boss c=start_dev_cmd config="some.config"|grep -v "==>"  in init.sh script and add as many shortcuts as reguired

if no config param is set, then boss.config is used

in order boss_rebar:run\5 to work properly with command line config param u need to add extra line in alternative configs, for example, if alternative is boss.test.config and boss was initiated with  ./rebar boss c=start_dev_cmd config="boss.test.config"

    {this_config, "boss.test.config"}, %if absent boss.config will be used

    {use_config, "boss.test-2.config"}, %use instead of this_config file 

so u can make  ./rebar boss c=start_dev_cmd config="env-1.config"|grep -v "==>"  in init.sh script

and then add {use_config, "env-2.config"}, in env-1.config , eventually env-2.config will be used.

what i posted before works the same, i.e. if u do not set config param in comand line, boss.config will be used as default and u can set alternative envs with {use_config, CONF_NAME}, no need to specify {this_config, CONF_NAME} in this case,

if both this_config and use_config are absent boss.config will be used.

[David Welton]

> I'm torn on whether or not to use dev-specific config files onto have
> dynamically loaded config sections of a single config.
>
> I wouldn't feel terribly comfortable doing *too* much hackery by way of
> precompiling config dynamically.

> That said, having it explicitly load a boss-dev.config or something like
> that would probably be the simplest change to add prod/dev config splits.

Yeah, as I said in my other email, I'd be happy to get away from
having CB be so dependent on weird compiler hacks, and do things in a
more Erlangish way.

Rather than have completely separate files though, what I'd ideally
like to see is have values from the dev or production files override
the main config file, so that most of the configuration can be
centralized and only bits and pieces customized as needed.

[Jesse Gumm]

Indeed. I've done config file merging before, but the merging is
always so... inconsistent. It's like some rules, you add to a list,
others, you replace a value altogether, then it ends up being a bit of
a mess.

...Anyway, I'm just thinking out loud.

I'll give some thought to this after I finish up my testing
experiments with boss_db.

-Jesse

> --
> You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss...@googlegroups.com.
> Visit this group at http://groups.google.com/group/chicagoboss.

> To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CA%2Bb9R_tMc4HyuftTQUAjHsCZrQfGPC3Q9oC6sxbvqnVacY8rtQ%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

[Nick Garanko]

Wouldn't it be nice to use boss.config as default config and add command line option with extra config file that can override main boss.config values?

(i.e. ./init(-dev).sh --extra-config=boss.conf.dev)

Kind regards,

Nikolay Garanko