| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
The checking of flags and the parsing of arguments is separated up.
|
| |
|
| |
`template` is not a kv-style argument, but a plain argument. If you give `template=app` on the command line, you get "template not found."
|
| |
|
|
|
|
| |
- Crashes in providers lib when no providers in a namespace are bare
- Making sure bareness matches semantics; i.e. a bare provider is
visible, a non-bare provider is hidden.
|
| | |
|
| |
|
|
|
|
|
| |
- Allow 'rebar3 help' to work and have it point to 'rebar3 help
<template>'
- show a 'template not found' message when a template is indeed not
found rather than crashing.
|
| | |
|
| |
|
|
|
|
|
| |
The first variable can be unkeyed and the provider will sub in the
variable name 'name'. Additionally, the built-in templates and
documentation have been updated so that 'appid' is now 'name' and the
alternative commands are shown.
|
| | |
|
| |
|
|
|
| |
This totally breaks compatibility with rebar2, and maybe it shouldn't
have.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
