Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin templates #987

Merged
merged 1 commit into from
Dec 21, 2015
Merged

Plugin templates #987

merged 1 commit into from
Dec 21, 2015

Conversation

ferd
Copy link
Collaborator

@ferd ferd commented Dec 19, 2015

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
Copy link
Collaborator

What do you mean callable only from the top?

For plugins using priv/ is probably ok.

@ferd
Copy link
Collaborator Author

ferd commented Dec 19, 2015

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
Copy link
Collaborator

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
Copy link
Collaborator Author

ferd commented Dec 19, 2015

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

@ferd
Copy link
Collaborator Author

ferd commented Dec 20, 2015

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

@ferd ferd changed the title WIP: Plugin templates Plugin templates Dec 20, 2015
@archaelus
Copy link
Contributor

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

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.
@ferd
Copy link
Collaborator Author

ferd commented Dec 20, 2015

Fixed & Amended.

tsloughter added a commit that referenced this pull request Dec 21, 2015
@tsloughter tsloughter merged commit d7def6e into erlang:master Dec 21, 2015
@ferd ferd deleted the plugin-templates branch December 21, 2015 22:43
@ferd
Copy link
Collaborator Author

ferd commented Dec 21, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants