lcfg

Table of Contents

• Introduction
• Dependencies
• Usage
  • project
    • deps
  • logging
  • Functions in config files
  • Referencing other config items

Introduction ↟

lcfg is the library behind the lfe.config file.

This library is intented to be used by projects during their creation, dependency download, compile, etc., phases. As such, this library should be "bootstrapped" (lfetool uses it and installs it into ~/.lfe/deps).

Dependencies ↟

This library requires only that LFE be installed.

Usage ↟

Usage is the same as any other Erlang or LFE library :-)

project ↟

deps ↟

Given an lfe.config (such as lfe.config.sample found in this repo) with project dependencies defined:

#(project (#(deps (#("rvirding/lfe" "develop")
                   #("lfex/lutil" "master")
                   "dysinger/lfesl"
                   "lfex/ltest"))))

Executing the following command will download the dependencies listed, circumventing rebar completely:

> (lcfg:clone-deps)
lfetool ~>> git: destination path 'deps/lfe' already exists ...
lfetool ~>> git: destination path 'deps/lutil' already exists ...
lfetool ~>> Cloning into deps/lfesl...
lfetool ~>> git: destination path 'deps/ltest' already exists ...
ok
>

Even though the configuration file is in LFE syntax, this is also usable from Erlang:

1> lcfg:'clone-deps'().
lfetool ~>> git: destination path 'deps/lfe' already exists ...
lfetool ~>> git: destination path 'deps/lutil' already exists ...
lfetool ~>> Cloning into deps/lfesl...
lfetool ~>> git: destination path 'deps/ltest' already exists ...
ok
2>

logging ↟

lcfg supports logging configuration. Currently the only supported logging backend is lager. The top-level logging configuration option has three sub-options:

• log-level
• backend
• options

The last is what gets passed to the backend. As such, it needs to hold all the information you want your backend to be configured with. See the sample lfe.config file for a working example of a lager configuration.

Functions in config files ↟

lcfg supports functions in config files. In order to work, the top-level tuple for the config item needs to be backquote'ed. For example, if the following
was saved to ./lfe.local:

#(project (#(deps (#("rvirding/lfe" "develop")
                   #("lfex/lutil" "master")
                   "dysinger/lfesl"
                   "lfex/ltest"))))
`#(opt-1 (,(lutil:get-lfe-version)))

When (lcfg-file:parse-local) is called, it would be rendered as:

> (lcfg-file:parse-local)
(#(project
   (#(deps
      (#("rvirding/lfe" "develop")
       #("lfex/lutil" "master")
       "dysinger/lfesl"
       "lfex/ltest"))))
 #(opt-1 ("0.9.0"))

Note that when calling (lcfg-file:read-local), top-level backquoteed items will be ignored, e.g.:

> (lcfg-file:read-local)
(#(project
   (#(deps
      (#("rvirding/lfe" "develop")
       #("lfex/lutil" "master")
       "dysinger/lfesl"
       "lfex/ltest"))))

Referencing other config items ↟

lcfg supports the ability to extract items that were configured in different (static, unevaluated) sections. For example, given this configuration:

#(project (#(deps (#("rvirding/lfe" "develop")
                   #("lfex/lutil" "master")
                   "dysinger/lfesl"
                   "lfex/ltest"))))
#(cfg-data (#(some (#(thing "else")
                    #(or "other")
                    #(can "be")
                    #(configured "here")))))
`#(opt-1 (,(lutil:get-lfe-version)))
`#(opt-2 (#(data-from-config ,(lcfg:get-in 'local '(cfg-data some can)))))

One can do this:

> (lcfg-file:parse-local)
(#(project
   (#(deps
      (#("rvirding/lfe" "develop")
       #("lfex/lutil" "master")
       "dysinger/lfesl"
       "lfex/ltest"))))
 #(cfg-data
   (#(some (#(thing "else") #(or "other") #(can "be") #(configured "here")))))
 #(opt-1 ("0.9.0"))
 #(opt-2 (#(data-from-config "be"))))