#Erlang #rebar3 #relx #OTP

OTP-21: New sys_config_src option in relx

With the release of OTP-21 and rebar3 3.6.0, which includes a new relx 3.25.0, there is better support for dynamic configuration of releases at runtime. If you are new to this concept checkout the rebar3 docs first No longer will you be forced to declare RELX_REPLACE_OS_VARS and convert strings to integers in your code because the sys.config file had to be valid Erlang terms when building the release. Instead, you can use {sys_config_src, "config/sys. ...

#Erlang #rebar3

Rebar3 Hex Plugin

No plugin is needed for using Hex packages in your project, covered in documentation here, but at this time the plugin rebar3_hex is needed for publishing. The plugin provides support for registering with hex.pm and publishing packages. For instructions on registering see the rebar3 hex.pm documentation, here we’ll cover publishing a package with some unique features to the rebar3 plugin. rebar3 hex cut The cut command provides some automation on top of publish. ...

#Erlang #rebar3

Rebar3 Features (part 6): _checkouts

In a build tool there is often a balancing act between ensuring repeatability and efficiency for the user. Wanting to make modifications on a dependency of your project is a common case of this. In rebar2 you could simply modify the source under deps/ and running rebar compile would pick those up. This meant that the contents of deps/ are not representative of the dependencies listed in rebar.config. With rebar3 a dependency is never rebuilt, even if a source file changes. ...

#Erlang #rebar3

Rebar3 Auto Compile and Load Plugin

During development the Erlang shell is often used for quickly testing functionality. Erlang’s ability to reload modules while running makes this workflow even more efficient. To go a step further in removing manual intervention tools like [sync]() and [active]() have been created. These libs will listen for file modifications, recompile and reload the changed modules. With rebar3 there is a plugin rebar3_auto which will start the shell, begin listening for modifications in the source directories of the project and recompile/reload when changes occur. ...

#Erlang #rebar3

Rebar3 Features (part 4): Profiles

Running tests and need meck or proper? Building docs and want edown? Bundling up a target system and want to include erts and turn off relx’s dev_mode? Rebar3 now has you covered for these scenarios through profiles. Profiles can be named with any atom, can add new items to the configuration, or prepend new options to existing elements, and multiple profiles can be combined themselves. The two special profiles are default and global. ...

#Erlang #rebar3

Rebar3 features (part 3): Overrides

What do you do when a dependency has settings in its rebar.config that are causing you problems? Maybe it includes dependencies that are not needed in the general case, like meck or edown. Or it could have set a required OTP version that isn’t accurate and you want to remove. Or the app could contain C code that needs compiling and had relied on rebar2’s port compiler. These problems often lead to forks of projects, which isn’t good for anyone, so in rebar3 we’ve added a feature called overrides. ...

#Erlang #rebar3

Rebar3 Features (part 2): Dependency Tree

rebar3 tree is a new command to allow the user to view what dependency pulled in each transitive dependency. This is especially useful with rebar3’s dependency resolution strategy of “first wins”. Thanks for pushing for this feature goes to Heinz N. Gies and inspiration comes from leiningen’s command lein deps :tree. For an example I’ve cloned chef-server and built oc_erchef under src/oc_erchef. It is unique because it has both a top level app oc_erchef under src/ as well as additional project apps under apps/. ...

#Erlang #rebar3

Rebar3 Features (part 1): Local install and upgrade

Update January 22, 2016: The original post has been modified to reflect that the commands install and upgrade were moved from the unstable namespace to the local namespace. Also added is use of the environment variable $REBAR3_ERL_ARGS in the run script which allows the user to specify custom Erlang VM arguments like: REBAR3_ERL_ARGS="+A10" rebar3 shell. Rebar3 comes with a lot of new and improved features. I’ll be publishing posts here to highlight some of these features over the coming weeks. ...