You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

192 lines
7.3 KiB

  1. # Templates #
  2. - [Default Variables](#default-variables)
  3. - [Global Variables](#global-variables)
  4. - [Batteries-Included Templates](#batteries-included-templates)
  5. - [Custom Templates](#custom-templates)
  6. ## Default Variables
  7. - `date`: defaults to today's date, under universal time, printed according to RFC 8601 (for example, `"2014-03-11"`)
  8. - `datetime`: defaults to today's date and time, under universal time, printed according to RFC 8601 (for example, `"2014-03-11T16:06:02+00:00"`).
  9. - `author_name`: Defaults to `"Anonymous"`
  10. - `author_email`: Defaults to `"anonymous@example.org"`
  11. - `apps_dir`: Directory where OTP applications should be created in release projects. Defaults to `"apps/"`.
  12. - `copyright_year`: Defaults to the current year, under universal time.
  13. ## Global Variables
  14. Global variables can be set by editing the file at `$HOME/.rebar3/templates/globals`:
  15. {variables, [
  16. {author_name, "My Name Is A String"},
  17. {copyright_year, "2014-2022", "The year or range of years for copyright"},
  18. {my_custom_var, "hello there"}
  19. ]}.
  20. This will let you define variables for all templates.
  21. Variables left undefined will be ignored and revert to the default value.
  22. The override order for these variables will be: Defaults < $HOME/.rebar3/templates/globals < command line invocation.
  23. ## Batteries-Included Templates ##
  24. Rebar3 ships with a few templates installed, which can be listed by calling `rebar3 new`:
  25. → ./rebar3 new
  26. app (built-in): OTP Application
  27. lib (built-in): OTP Library application (no processes)
  28. release (built-in): OTP Release structure for executable programs
  29. plugin (built-in): Rebar3 plugin
  30. Any custom plugins would be followed as `<plugin_name> (custom): <description>`.
  31. Details for each individual plugin can be obtained by calling `rebar3 new help <plugin>`:
  32. → ./rebar3 new help plugin
  33. plugin:
  34. built-in template
  35. Description: Rebar3 plugin
  36. Variables:
  37. name="myplugin" (Name of the plugin)
  38. desc="A rebar plugin" (Short description of the plugin's purpose)
  39. date="2014-11-10"
  40. datetime="2014-11-10T18:29:41+00:00"
  41. author_name="Anonymous"
  42. author_email="anonymous@example.org"
  43. copyright_year="2014"
  44. apps_dir="apps/" (Directory where applications will be created if needed)
  45. All the variables there have their default values shown, and an optional explanation in parentheses.
  46. The variables can also be [overriden globally](#global-variables).
  47. A template can be run by calling:
  48. → ./rebar3 new plugin name=demo author_name="Fred H."
  49. ...
  50. Alternatively, the `name` variable is special -- if the first argument to a template has no key associated with it, `name` is automatically added. The call above is therefore equivalent to:
  51. → ./rebar3 new plugin demo author_name="Fred H."
  52. ...
  53. Then go to the directory created for the project by rebar3.
  54. ## Custom Templates ##
  55. Custom templates can be added in `$HOME/.rebar3/templates/`. Each template is at least two files:
  56. - `my_template.dtl`: There can be many of these files. They are regular Erlang files using the django template syntax for variable replacements.
  57. - `my_template.template`; Called the *template index*, there is one per template callable from `rebar3`. This one will be visible when calling `rebar3 new my_template`. This file regroups the different \*.dtl files into a more cohesive template.
  58. ### File Syntax ###
  59. #### Template Index ####
  60. The following options are available:
  61. {description, "This template does a thing"}.
  62. {variables, [
  63. {var1, "default value"},
  64. {var2, "default", "explain what this does in help files"},
  65. {app_dir, ".", "The directory where the application goes"}
  66. ]}.
  67. {dir, "{{appdir}}/src"}.
  68. {file, "mytemplate_README", "README"}.
  69. {chmod, "README", 8#644}.
  70. {template, "myapp/myapp.app.src.dtl", "{{appdir}}/src/{{name}}.app.src"}.
  71. Specifically:
  72. - `description`: takes a string explaining what the template is for.
  73. - `variables`: takes a list of variables in two forms:
  74. - `{Name, DefaultString, HelpString}`;
  75. - `{Name, DefaultString}`.
  76. - `{dir, TemplatablePathString}`: creates a given directory. Variable names can be used in the path name.
  77. - `{file, FilePath, DestFilePath}`: copies a file literally to its destination.
  78. - `{template, DtlFilePath, TemplatablePathString}`: evaluates a given template. The `DtlFilePath` is relative to the template index.
  79. - `{chmod, FilePath, Int}`: changes the permission of a file, using the integer value specified. Octal values can be entered by doing `8#640`.
  80. ### Example ###
  81. As an example, we'll create a template for Common Test test suites. Create the directory structure `~/.rebar/templates/` and then go in there.
  82. We'll start with an index for our template, called `ct_suite.template`:
  83. ```erlang
  84. {description, "A basic Common Test suite for an OTP application"}.
  85. {variables, [
  86. {name, "suite", "Name of the suite, prepended to the standard _SUITE suffix"}
  87. ]}.
  88. {dir, "test"}.
  89. {template, "ct_suite.erl.dtl", "test/{{name}}_SUITE.erl"}.
  90. ```
  91. This tells rebar3 to create the test directory and to evaluate an [ErlyDTL](https://github.com/erlydtl/erlydtl) template. All the paths are relative to the current working directory.
  92. Let's create the template file:
  93. ```erlang
  94. -module({{name}}_SUITE).
  95. -include_lib("common_test/include/ct.hrl").
  96. -include_lib("eunit/include/eunit.hrl"). % Eunit macros for convenience
  97. -export([all/0
  98. ,groups/0
  99. %,init_per_suite/1, end_per_suite/1
  100. %,init_per_group/2, end_per_group/2
  101. ,init_per_testcase/2, end_per_testcase/2
  102. ]).
  103. -export([fail/1]).
  104. all() -> [fail].
  105. groups() -> [].
  106. init_per_testcase(_Name, Config) -> Config.
  107. end_per_testcase(_Name, _Config) -> ok.
  108. fail(_Config) ->
  109. ?assert(false).
  110. ```
  111. This one does very simple variable substitution for the name (using `{{name}}`) and that's all it needs.
  112. Let's get to any existing project you have and try it:
  113. → ./rebar3 new
  114. app (built-in): OTP Application
  115. ct_suite (custom): A basic Common Test suite for an OTP application
  116. lib (built-in): OTP Library application (no processes)
  117. release (built-in): OTP Release structure for executable programs
  118. plugin (built-in): Rebar3 plugin
  119. The first line shows that our `ct_suite` temlate has been detected and is usable.
  120. Let's look at the details:
  121. → ./rebar3 new help ct_suite
  122. ct_suite:
  123. custom template (/home/ferd/.rebar3/templates/ct_suite.template)
  124. Description: A basic Common Test suite for an OTP application
  125. Variables:
  126. name="suite" (Name of the suite, prepended to the standard _SUITE suffix)
  127. date="2014-11-10"
  128. datetime="2014-11-10T18:46:33+00:00"
  129. author_name="Anonymous"
  130. author_email="anonymous@example.org"
  131. copyright_year="2014"
  132. apps_dir="apps/" (Directory where applications will be created if needed)
  133. The documentation from variables and the description are well in place. To apply the template, go to any of your OTP application's top-level directory:
  134. → ./rebar3 new ct_suite demo
  135. ===> Writing test/demo_SUITE.erl
  136. And you will see the code in place.