Plugin templates

[ferd]

This is a proof of concept, untested in practice, that goes and dig in the plugin paths for all plugins of a project's priv/ dir, for .template files the way we do it in ~/.config/rebar3. This lets a plugin define templates to be loaded:

$ rebar3 new
app (built-in): Complete OTP Application structure.
cmake (built-in): Standalone Makefile for building C/C++ in c_src
ct_suite (custom): A basic Common Test suite for an OTP application
escript (built-in): Complete escriptized application structure
fn_app (custom): Efene Application
lib (built-in): Complete OTP Library application (no processes) structure
plugin (built-in): Rebar3 plugin project structure
proper (plugin): A basic PropEr suite for an OTP application
release (built-in): OTP Release structure for executable programs

$ rebar3 new help proper
proper:
        plugin template (/home/ferd/code/self/sdiff/_build/default/plugins/rebar3_proper/priv/proper_tpl/proper.template)
        Description: A basic PropEr suite for an OTP application
        Variables:
                name="suite" (Name of the suite, appended to the prop_ suffix)
                date="2015-12-19"
                datetime="2015-12-19T03:48:31+00:00"
                author_name="Fred Hebert"
                author_email="mononcqc@ferd.ca"
                copyright_year="2015"
                apps_dir="apps" (Directory where applications will be created if needed)

→ 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.

Things I'd like to figure out:

• Are we comfortable with being callable only from the top for these (aside from global plugins)
• Should we avoid forcing stuff into priv/ for this and rather mandate a template/ or templates/ directory for plugins
• Is the order of priority correct? I went with Built-in > .config > .plugins, such that someone could ensure plugins do not crush their own private templates.
• How the hell to test that since it requires a mock project with a mock plugin and blergh

Note: this PR builds on #986, I can rebase it out if wanted.

CC @archaelus

[tsloughter]

What do you mean callable only from the top?

For plugins using priv/ is probably ok.

[ferd]

Only from the top as in if you

$ cd test/
$ rebar3 new

then new loses sight of _build/ and rebar.config and can no longer find non-global plugins.

My scare with priv/ is that if anything uses a .template file (such as a build tool of some sort), then we have weird interactions with rebar3. I could also force it to look in priv/templates I guess.

[tsloughter]

But you are only looking in plugins, right? That is what I meant about it probably being fine for plugins, they are rebar3 specific already.

[ferd]

Alright. I can leave it as-is then. I'll try to see how to test this in the upcoming days.

[ferd]

Test added. It doesn't check priorities but eeeh. It otherwise executes a plugin template off a _checkouts directory fine.

[archaelus]

IMO: it's fine for templates to only really be usable at the top level (rebar3 new only working right at the top level). The top level project is the one you're working on, (though if you have an apps/component{1,2,3} structure, it working there would be good too). I guess it should work anywhere in the top-level-project repo that is for erlang or related stuff.

I think the priority order should be rebar built-in < plugins < my own templates in ~/.config/rebar3. If I've gone to the effort of writing templates in my home dir, I probably want those executed in preference to others (the ability to override/choose which would be great but not required). Plugins probably have a better idea of what people want, and built-ins are the most generic/least specific, so should be the lowest priority (imo, ymmv, etc).

[ferd]

Fixed & Amended.

[ferd]

Doc updated at http://www.rebar3.org/v3.0/docs/using-templates#section-plugin-templates