| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
This replaces all deprecated function usage by alternative ones based on
a version switch enacted at compile time, preventing all warnings.
This will likely introduce some possible runtime errors in using a
Rebar3 compiled on OTP-20 or OTP-21 back in versions 19 and earlier, but
we can't really work around that.
A bunch of dependencies have been updated to support OTP-21 without
warnings as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done through 3 main change groups:
- replacing `~s` by `~ts` in format strings, so that strings that
contain unicode are properly printed rather than crashing
- adding the `unicode` argument to all function of the `re` module to
ensure transformations on strings containing unicode data are valid
instead of crashing (see issue #1302)
- replacing `ec_cnv:to_binary/1` and `ec_cnv:to_list/1` with matching
functions in `rebar_utils`.
The last point has been done, rather than modifying and updating erlware
commons, because binary and list conversions can be a contentious
subject. For example, if what is being handled is actually bytes from a
given binary stream, then forcing a byte-oriented interpretation of the
data can corrupt it. As such, it does not appear safe to modify erlware
commons' conversion functions since it may not be safe for all its
users.
Instead, rebar3 reimplements a subset of them (only converting
atoms and chardata, ignoring numbers) with the explicit purpose of
handling unicode string data.
Tests were left as unchanged as possible. This may impact the ability to
run rebar3's own suites in a unicode path, but respects a principle of
least change for such a large patch.
|
| |
|
|
|
| |
Did not really know how to automate the testing for this, did it by
hand.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When the `new` command is run from a locally installed rebar3 (`rebar3
local install`), the builtin templates would be labelled as custom
because of directories.
This patch fixes it by splitting off the rebar3 priv dir from the user's
configured plugin path for custom ones, and introducing a new internal
label for builtins (since handling must remain different from escripts)
This fixes issue #819
|
| |
|
|
|
|
|
| |
The regex mistakenly matched too many files (any character followed by
an underscore) rather than only files starting in '._'
This properly escapes the expressions to work in all cases.
|
| | |
|
| |
|
|
| |
added
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets a plugin define templates to be loaded:
$ rebar3 new
...
proper (plugin): A basic PropEr suite for an OTP application
...
$ rebar3 new help proper
proper:
plugin template (...)
Description: A basic PropEr suite for an OTP application
Variables:
name="suite" (...)
...
→ rebar3 new proper fakesuite
===> Writing test/prop_fakesuite.erl
In this case, proper is a fake template file I've put by hand in
_build/default/plugins/rebar3_proper/priv/<somename>/, meaning it will
only work as far as it's called from the project's root.
The priority order of plugins is now .config > plugin > built-in, such
that someone could ensure plugins do not crush their own private
templates, but also that custom or plugin templates do overtake built-in
ones. It used to be Built-in > .config only.
Templates are searched for recursively in the priv/ directory of
plugins.
|
| |
|
|
|
|
|
|
| |
This should fix #955
The test is implicit as a bad index previously silently crashed rebar3.
By adding the bad index to the `new` suite's files, we can show that
things keep running.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
error before:
===> Uncaught error: {'EXIT',
{badarg,
[{io,format,
[<0.23.0>,
"\e[0;36m===> Skipping template ~p, due to presence of a custom template at ~s~n~n\e[0m",
["/home/mariano/.config/rebar3/templates/fn_app/fn_app.template"]],
[]},
{rebar_templater,prioritize_templates,2,
[{file,"src/rebar_templater.erl"},{line,330}]},
{rebar_templater,find_templates,1,
[{file,"src/rebar_templater.erl"},{line,274}]},
{rebar_templater,new,4,
[{file,"src/rebar_templater.erl"},{line,47}]},
{rebar_prv_new,do,1,
[{file,"src/rebar_prv_new.erl"},{line,44}]},
{rebar_core,do,2,
[{file,"src/rebar_core.erl"},{line,129}]},
{rebar3,main,1,
[{file,"src/rebar3.erl"},{line,46}]},
{escript,run,2,
[{file,"escript.erl"},{line,752}]}]}}
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
- Includes tests for templates and their application
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Templates should only be in ~/.rebar3/templates and the built-in ones,
bar some specific overrides someone may want.
Looking recursively for templates in the CWD (.) may end up searching
nearly forever if the project is being created at the top of a very deep
directory tree, with extremely unlikely chances to find relevant
templates.
It causes more problems than benefits.
|
| |
|
|
|
|
| |
- The OTP app template now adds the supevisor
- The default apps_dir value does not contain the trailing '/' that the
template index already added.
|
| | |
|
| | |
|
| |
|
|
|
| |
This totally breaks compatibility with rebar2, and maybe it shouldn't
have.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
If you happen to fetch a zip archive of the git repo and try to build
from that, you may, for example, ask erlc to build src/._rebar.erl.
._* are OS X resource forks and not real .erl files. This may also
happen with network filesystems on OS X. To fix that, limit the
files compiled by rebar to include only those which start with
a letter or a digit.
|
| |\
| |
| | |
Switch template instructions
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Running 'rebar list-templates' can take quite a long time, when it has
to search the file system. To fix that, make list-templates not recurse
by default. To enable recursion, run 'rebar -r list-templates'.
|
| | | |
|
| |/ |
|
| | |
|
