I am abstracting some code into a "library" that can be included in other
applications. This library requires a fair bit of config options, what is
the recommended approach here when starting it up?
I noticed some libraries like cowboy, you pass all the configs into the
main start_http() method, others use include files.
Is there a preferred mechanism here when there are 20-25 config options
for the included application?
On Fri, Nov 16, 2012 at 6:28 PM, AD <straightfl...@gmail.com> wrote:
> Hello,
> I am abstracting some code into a "library" that can be included in other
> applications. This library requires a fair bit of config options, what is
> the recommended approach here when starting it up?
> I noticed some libraries like cowboy, you pass all the configs into the
> main start_http() method, others use include files.
> Is there a preferred mechanism here when there are 20-25 config options
> for the included application?
On Fri, Nov 16, 2012 at 8:28 AM, AD <straightfl...@gmail.com> wrote:
> Hello,
> I am abstracting some code into a "library" that can be included in other
> applications. This library requires a fair bit of config options, what is
> the recommended approach here when starting it up?
> I noticed some libraries like cowboy, you pass all the configs into the
> main start_http() method, others use include files.
> Is there a preferred mechanism here when there are 20-25 config options for
> the included application?
The inets application is a good example of how one can hide a lot of
complexity behind the application abstraction, and use Erlang's
standard app config mechanism to customize behavior.
On Fri, Nov 16, 2012 at 8:35 AM, Max Lapshin <max.laps...@gmail.com> wrote:
> application:load(stockdb),
> application:set_env(stockdb, key, value),
> application:start(stockdb),
Though this pattern just shifts the question -- where does Value come from?
If you use the standard pattern in Erlang of application config files,
Value is defined in that file and the application can use
application:get_env without the additional burden of app config
management.
IMO application:start/1 is also a bad smell outside dev/test modes.
When you deploy as an Erlang release, applications are started by the
init system process.
That said, doing releases in Erlang is *still very painful*, so it's
understandable that there's a lot of roll your own system
config/startup patterns in the field. I tend to push through to get
releases working because at runtime the scheme works very well.
> On Fri, Nov 16, 2012 at 6:28 PM, AD <straightfl...@gmail.com> wrote:
>> Hello,
>> I am abstracting some code into a "library" that can be included in other
>> applications. This library requires a fair bit of config options, what is
>> the recommended approach here when starting it up?
>> I noticed some libraries like cowboy, you pass all the configs into the
>> main start_http() method, others use include files.
>> Is there a preferred mechanism here when there are 20-25 config options
>> for the included application?
> IMO application:start/1 is also a bad smell outside dev/test modes.
> When you deploy as an Erlang release, applications are started by the
> init system process.
I've tried to use releases in erlyvideo for a year and totally refused from
then and I don't see even a single reason for me to return back to them.
So, there is nothing bad in application:start/1, it is a good way to deploy
and launch system.
There is a nice startup function now in erlyvideo, that does all setup
(which differs for runtime and for tests), it loads
all data from config file.
application config file is a bad place for configuring your application,
because it generates nowadays from app.src and exists somewhere in
/usr/lib/...
I would _really_ propose you to came back to releases. Rebar + reltool makes distribution of you application in a form of self contained tarball.
Of corse there is nothing bad with application:start but I hardly see how your handle node and application restart. Proper release config + heart bring couple of advantages on fault handling.
BTW, there is no need to to touch app.src file for application configuration. All applications are configured through sys.config. You can also make your config file to be placed into /etc or even make hierarchy of configs.
> IMO application:start/1 is also a bad smell outside dev/test modes.
> When you deploy as an Erlang release, applications are started by the
> init system process.
> I've tried to use releases in erlyvideo for a year and totally refused from then and I don't see even a single reason for me to return back to them. So, there is nothing bad in application:start/1, it is a good way to deploy and launch system.
> There is a nice startup function now in erlyvideo, that does all setup (which differs for runtime and for tests), it loads
> all data from config file.
> application config file is a bad place for configuring your application, because it generates nowadays from app.src and exists somewhere in /usr/lib/...
On Fri, Nov 16, 2012 at 9:19 AM, Max Lapshin <max.laps...@gmail.com> wrote:
>> IMO application:start/1 is also a bad smell outside dev/test modes.
>> When you deploy as an Erlang release, applications are started by the
>> init system process.
> I've tried to use releases in erlyvideo for a year and totally refused from
> then and I don't see even a single reason for me to return back to them. So,
> there is nothing bad in application:start/1, it is a good way to deploy and
> launch system.
Understood. But there is a payoff in getting this to work. Understood though :)
I want to set aside some time to check out Eric Merrit's relcool (I
came up with the name :)
> There is a nice startup function now in erlyvideo, that does all setup
> (which differs for runtime and for tests), it loads
> all data from config file.
Reinventing the wheel, but that's cool - it's not a complicated wheel.
> application config file is a bad place for configuring your application,
> because it generates nowadays from app.src and exists somewhere in
> /usr/lib/...
> configuration file lives in /etc/
You're confused. App config has nothing to do with app.src and
certainly lives in /etc/
Thank you, guys, a lot, but I'm not going to return to releases =)
erlyvideo is just a plain unix software, like apache or sendmail, that is
installed by people, that are hearing about erlang for the first time.
They can modify only one file in /etc/, so I need to read it before
startup. But there may not be this file, so I need to look for in in other
place.
I really don't see any use in releases for me, so my way of configuring
applications inside erlang node is very, very convenient and it is
_working_. Working in _my practice_.
On Fri, Nov 16, 2012 at 7:30 PM, Garrett Smith <g...@rre.tt> wrote:
> On Fri, Nov 16, 2012 at 9:19 AM, Max Lapshin <max.laps...@gmail.com>
> wrote:
> >> IMO application:start/1 is also a bad smell outside dev/test modes.
> >> When you deploy as an Erlang release, applications are started by the
> >> init system process.
> > I've tried to use releases in erlyvideo for a year and totally refused
> from
> > then and I don't see even a single reason for me to return back to them.
> So,
> > there is nothing bad in application:start/1, it is a good way to deploy
> and
> > launch system.
> Understood. But there is a payoff in getting this to work. Understood
> though :)
> I want to set aside some time to check out Eric Merrit's relcool (I
> came up with the name :)
> > There is a nice startup function now in erlyvideo, that does all setup
> > (which differs for runtime and for tests), it loads
> > all data from config file.
> Reinventing the wheel, but that's cool - it's not a complicated wheel.
> > application config file is a bad place for configuring your application,
> > because it generates nowadays from app.src and exists somewhere in
> > /usr/lib/...
> > configuration file lives in /etc/
> You're confused. App config has nothing to do with app.src and
> certainly lives in /etc/
But just a point of clarification -- releases are hard for release
engineers, not for end users. I deploy all Erlang projects as releases
for that reason. You get a nice distribution that can be configured
trivially with a single config file and further refined with command
line options.
There is a theoretical downside to asking users to edit Erlang term
files. I treat this as a UI problem to config and so have used
converters from, say YML, to Erlang config files that are run at
startup so users don't get into that layer. But since the Erlang init
process is so central to Erlang itself, I prefer to leverage it rather
than roll something different.
On Fri, Nov 16, 2012 at 9:40 AM, Max Lapshin <max.laps...@gmail.com> wrote:
> Thank you, guys, a lot, but I'm not going to return to releases =)
> erlyvideo is just a plain unix software, like apache or sendmail, that is
> installed by people, that are hearing about erlang for the first time.
> They can modify only one file in /etc/, so I need to read it before startup.
> But there may not be this file, so I need to look for in in other place.
> I really don't see any use in releases for me, so my way of configuring
> applications inside erlang node is very, very convenient and it is
> _working_. Working in _my practice_.
> On Fri, Nov 16, 2012 at 7:30 PM, Garrett Smith <g...@rre.tt> wrote:
>> On Fri, Nov 16, 2012 at 9:19 AM, Max Lapshin <max.laps...@gmail.com>
>> wrote:
>> >> IMO application:start/1 is also a bad smell outside dev/test modes.
>> >> When you deploy as an Erlang release, applications are started by the
>> >> init system process.
>> > I've tried to use releases in erlyvideo for a year and totally refused
>> > from
>> > then and I don't see even a single reason for me to return back to them.
>> > So,
>> > there is nothing bad in application:start/1, it is a good way to deploy
>> > and
>> > launch system.
>> Understood. But there is a payoff in getting this to work. Understood
>> though :)
>> I want to set aside some time to check out Eric Merrit's relcool (I
>> came up with the name :)
>> > There is a nice startup function now in erlyvideo, that does all setup
>> > (which differs for runtime and for tests), it loads
>> > all data from config file.
>> Reinventing the wheel, but that's cool - it's not a complicated wheel.
>> > application config file is a bad place for configuring your application,
>> > because it generates nowadays from app.src and exists somewhere in
>> > /usr/lib/...
>> > configuration file lives in /etc/
>> You're confused. App config has nothing to do with app.src and
>> certainly lives in /etc/
