Skip to content

Commit

Permalink
Revisions on latest rebar3 changes
Browse files Browse the repository at this point in the history
Also adding Tristan to thanks since he did the review on this one.
  • Loading branch information
ferd committed Apr 6, 2016
1 parent 85ffc54 commit d44ac26
Show file tree
Hide file tree
Showing 3 changed files with 11 additions and 17 deletions.
2 changes: 1 addition & 1 deletion 000-copyright.tex
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@

Thanks for the additional work, reviewing, and/or editing done by:

\emph{Jacob Vorreuter}, \emph{Seth Falcon}, \emph{Raoul Duke}, \emph{Nathaniel Waisbrot}, \emph{David Holland}, \emph{Alisdair Sullivan}, \emph{Lukas Larsson}, \emph{Tim Chevalier}, \emph{Paul Bone}, \emph{Jonathan Roes}, \emph{Roberto Aloi}, and \emph{Dmytro Lytovchenko}.
\emph{Jacob Vorreuter}, \emph{Seth Falcon}, \emph{Raoul Duke}, \emph{Nathaniel Waisbrot}, \emph{David Holland}, \emph{Alisdair Sullivan}, \emph{Lukas Larsson}, \emph{Tim Chevalier}, \emph{Paul Bone}, \emph{Jonathan Roes}, \emph{Roberto Aloi}, \emph{Dmytro Lytovchenko}, and \emph{Tristan Sloughter}.

\null
\vfill
Expand Down
4 changes: 2 additions & 2 deletions 101-diving.tex
Original file line number Diff line number Diff line change
Expand Up @@ -112,9 +112,9 @@ \subsection{Dependencies}
\section{OTP Releases}
\label{sec:dive-otp-releases}

OTP releases are not a lot harder to understand than most OTP applications you'll encounter in the wild. A release is a set of OTP applications packaged in a production-ready manner so it boots and shuts down without needing to manually call \function{application:start/2} for any app. Of course there's a bit more to releases than that, but generally, the same discovery process used for individual OTP applications will be applicable here.
OTP releases are not a lot harder to understand than most OTP applications you'll encounter in the wild. A release is a set of OTP applications packaged in a production-ready manner so it boots and shuts down without needing to manually call \function{application:start/2} for any app. Compiled releases may contain their own copy of the Erlang virtual machine with more or less libraries than the default distribution, and can be ready to run standalone. Of course there's a bit more to releases than that, but generally, the same discovery process used for individual OTP applications will be applicable here.

You'll usually have a file named \filename{relx.config} or a \term{relx} tuple in a \filename{rebar.config} file, which will state which applications are part of the release and some options regarding their packaging. Relx-based releases can be understood by reading the project's wiki\footnote{\href{https://github.com/erlware/relx/wiki}{https://github.com/erlware/relx/wiki}}, or their documentation on the documentation sites of \app{rebar3}\footnote{\href{https://www.rebar3.org/docs/releases}{https://www.rebar3.org/docs/releases}} or \filename{erlang.mk}\footnote{\href{http://erlang.mk/guide/relx.html}{http://erlang.mk/guide/relx.html}}.
You'll usually have a file named \filename{relx.config} or a \term{relx} tuple in a \filename{rebar.config} file, which will state which top-level applications are part of the release and some options regarding their packaging. Relx-based releases can be understood by reading the project's wiki\footnote{\href{https://github.com/erlware/relx/wiki}{https://github.com/erlware/relx/wiki}}, or their documentation on the documentation sites of \app{rebar3}\footnote{\href{https://www.rebar3.org/docs/releases}{https://www.rebar3.org/docs/releases}} or \filename{erlang.mk}\footnote{\href{http://erlang.mk/guide/relx.html}{http://erlang.mk/guide/relx.html}}.

Other systems may depend on the configuration files used by \module{systools} or \module{reltool}, which will state all applications part of the release and a few\footnote{A lot} options regarding their packaging. To understand them, I recommend \href{http://learnyousomeerlang.com/release-is-the-word}{reading existing documentation on them}.

Expand Down
22 changes: 8 additions & 14 deletions 102-building.tex
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ \subsection{OTP Applications}

What's new in this one is the \filename{\_build/} directory and the \filename{rebar.lock} file, which will be generated automatically by \app{rebar3}\footnote{Some people package \app{rebar3} directly in their application. This was initially done to help people who had never used rebar3 or its predecessors use libraries and projects in a boostrapped manner. Feel free to install rebar3 globally on your system, or keep a local copy if you require a specific version to build your system.}.

This is the directory where \app{rebar3} places all build artifacts for a project, including local copies of libraries and packages required for it to work. No mainstream Erlang tool installs packages globally\footnote{except as a cache}, preferring to instead keep everything project-local to avoid inter-project conflicts.
This is the directory where \app{rebar3} places all build artifacts for a project, including local copies of libraries and packages required for it to work. No mainstream Erlang tool installs packages globally\footnote{Except as a local cache of unbuilt packages.}, preferring to instead keep everything project-local to avoid inter-project conflicts.

Such dependencies can be specified for \app{rebar3} by adding a few config lines to \filename{rebar.config}:

Expand All @@ -41,17 +41,10 @@ \subsection{OTP Applications}
%% Hex.pm Packages
myapp,
{myapp,"1.0.0"},
{myapp, {pkg, myapp_fork}}, % myapp under a different package name
{myapp, "1.0.0", {pkg, myapp_fork}},
%% source dependencies
{myapp, {git, "git://github.com/user/myapp.git"}},
{myapp, {git, "http://github.com/user/myapp.git"}},
{myapp, {git, "https://github.com/user/myapp.git"}},
{myapp, {git, "git@github.com:user/myapp.git"}},
{myapp, {hg, "https://othersite.com/user/myapp"}},
{myapp, {git, "git://github.com/user/myapp.git", {ref, "aef728"}}},
{myapp, {git, "git://github.com/user/myapp.git", {branch, "master"}}},
{myapp, {git, "git://github.com/user/myapp.git", {tag, "3.0.0"}}}
{myapp, {git, "https://github.com/user/myapp.git", {branch, "master"}}},
{myapp, {hg, "https://othersite.com/user/myapp", {tag, "3.0.0"}}}
]}.
\end{VerbatimText}

Expand All @@ -64,7 +57,7 @@ \subsection{OTP Applications}
\subsection{OTP Releases}
\label{subsec:building-otp-releases}

For releases, the structure should can a bit different\footnote{I say \emph{can} because many Erlang developers put their final system under a single top-level application (in \filename{src}) and a bunch of follower ones as dependencies, which is less than ideal for distribution purposes and risks conflicting with assumptions on directory structures made by OTP. People who do that tend to build from source on the production servers and run custom commands to boot their applications.}. Releases are collections of applications, and their structures may reflect that.
For releases, the structure can a bit different. Releases are collections of applications, and their structures may reflect that.

Instead of having a top-level app alone in \filename{src}, applications can be nested one level deeper in a \filename{apps} or \filename{lib} directory:

Expand All @@ -76,13 +69,13 @@ \subsection{OTP Releases}
- myapp2/
- src/
doc/
deps/
LICENSE.txt
README.md
rebar.config
rebar.lock
\end{VerbatimRaw}

This structure lends itself to generating releases where multiple OTP applications under your control are used to generate them. Both \app{rebar3} and \app{erlang.mk} rely on the \app{relx} library to assemble releases. Other tools such as Systool and Reltool have been covered before\footnote{\href{http://learnyousomeerlang.com/release-is-the-word}{http://learnyousomeerlang.com/release-is-the-word}}, and can allow the user plenty of power if they do not like what they would get otherwise.
This structure lends itself to generating releases where multiple OTP applications under your control under a single code repository. Both \app{rebar3} and \app{erlang.mk} rely on the \app{relx} library to assemble releases. Other tools such as Systool and Reltool have been covered before\footnote{\href{http://learnyousomeerlang.com/release-is-the-word}{http://learnyousomeerlang.com/release-is-the-word}}, and can allow the user plenty of power if they do not like what they would get otherwise.

A \app{relx} configuration tuple (within \filename{rebar.config}) for the directory structure above would look like:

Expand All @@ -95,7 +88,8 @@ \subsection{OTP Releases}
]}
\end{VerbatimText}

Calling \command{rebar3 release} will build a release, to be found in the \filename{\_build/<profile>/rel/} directory. Calling \command{rebar3 tar} will generate a tarball ready to be deployed.
Calling \command{rebar3 release} will build a release, to be found in the \filename{\_build/default/rel/} directory. Calling \command{rebar3 tar} will generate a tarball at\\
\filename{\_build/default/rel/demo/demo-1.0.0.tar.gz}, ready to be deployed.

\section{Supervisors and start\_link Semantics}
\label{sec:supervisors-and-start-link-semantics}
Expand Down

0 comments on commit d44ac26

Please sign in to comment.