Port rebar2 LFE compiler functionality to rebar3 about rebar3 HOT 17 CLOSED

Note sure what's needed for this yet; currently reviewing rebar3 source and comparing to rebar2.

from rebar3.

Awesome! I'd suggest looking at http://rebar3.herokuapp.com/static/plugins.html and the erlydtl provider https://github.com/rebar/rebar3/blob/master/src/rebar_prv_erlydtl_compiler.erl

Though I want to modify the erlydtl provider a bit and may pull it out into a plugin instead of being in rebar3.

The main difference from rebar2 is that it won't simply run when you call compile. It is more like leiningen in that respect.

But there are support for hooks, which even the provider can add itself. So maybe having lfe hook into the compile provider will be a good way to have it also run when rebar3 compile is called.

from rebar3.

Your comment came just in time ... I was trying to figure out what rebar3 was going, as rebar2 automatically picked up lfe files during compile. I'll follow the trail you've outlined ... and be back with questions :-)

from rebar3.

Also, work for this ticket is going here:

• https://github.com/oubiwann/rebar3/tree/add-lfe-compiler

from rebar3.

Okay, I've got it ported over. It's acting as a provider right now -- smooth as silk :-) Really nice job on the rebar3 architecture.

This has lead me to several related thoughts, though... if this isn't the best forum to chat about these, let me know what you'd prefer.

Thoughts:

• the lfe compiler provider, as it is implemented right now, is named "lfecompile" so "rebar lfecompile" is what the user types on the command line
• there are potentially very many LFE plugins/providers that could be added ... lfe* commands galore; I'd imagine this would get cumbersome, resulting in a lot of output in rebar3 help
• My organizational instincts make me want to create a new provider called "lfe" that is a dispatcher for all other providers that register as lfe plugin providers (not sure if that's how providers work ... still need to look into that)

So, this leads me to this:

• should the work from this branch wait and be moved over into a collection of LFE community rebar3 providers?
• does it make sense to have a top-level LFE provider, with sub-providers under it? Thus allowing for things like rebar3 lfe compile, rebar3 lfe repl, rebar3 lfe new <proj type> <proj name>, etc.?

(Oh dear, that last example has me thinking about sub-sub-providers now ... registering plugins as providers for the "new" provider which is a provider for the "lfe" provider ...)

from rebar3.

Hm, I hadn't thought about sub-providers before. The way I figured it would work would be like the help provider:

{lfe_task, undefined, undefined, string, "LFE task to run."}

And then you'd have rebar3 lfe compile and in the lfe provider proplists:get_value(lfe_task, Args, undefined) would return "compile".

I'd also suggest breaking the lfe provider out into its own repo. This way it can evolve without needing someone to merge changes into rebar/rebar3. That has been a pain for both sides with rebar2.

We plan to have "official" or something plugins like LFE that'll be clearly displayed on the webpage and README and support for installing them with the package manager.

from rebar3.

I've finally had a chance to come back to this :-)

I just looked at rebar_prv_help:help , which is called when one enters rebar help from the command line, and I wanted to get a refinement on your recommendation for the case of lfetool.

Supposition:

An Erlang sub-community will be producing a whole bunch of rebar3 plugins that will not be top-level rebar plugins, but will only make sense within their own context, e.g., rebar3 lfe compile, rebar3 lfe compile , rebar3 lfe new library <name>, rebar3 lfe new service <name>, rebar3 lfe commands, etc. I could see not only projects like LFE, Elixir, Luerl, doing this, but also projects like Cowboy, Chicago Boss, and others.

Query:

Given that context, would you recommend:

• having a dispatch function in the main LFE plugin module (e.g., like rebar_prv_help:help) and
• implementing a function (like rebar_state:providers)?

Is so, would you recommend:

• maintaining a separate state record from what rebar3 uses or
• augmenting the rebar3 state record and passing that around? (so that rebar and the LFE plugins would use the same state)

Finally, are the answers to the questions actually part of the as-yet defined plugin system you were talking about? ;-)

Thanks again!

from rebar3.

I think a dispatch in the main lfe plugin module would probably work well. We can probably also consider reusing providers for that.

I don't know for sure this will work cleanly, but it may :)

I would think using the rebar state record/module we can add an addition element for storing a dict or list a plugin can keep state, or simply use your own state record in addition to the rebar state.

You are a guinea pig on this :), we do not yet have a defined plugin system outside of providers.

from rebar3.

Would a provider like 'do' but named 'lfe' work for this?

from rebar3.

Yea! That may be perfect. I'll look at making do less special, so a plugin can create its own.

from rebar3.

@ferd Nice :-)

@tsloughter Let me know when you've got that added to providers, and I'll take a look at it (i.e., ask you lots of annoying questions!)

from rebar3.

Taking me a little longer than expected. I think I'm going to extend providers to support subcommands.

from rebar3.

Trying to decide if each subcommand has to be a provider or if you can just define subcommands as functions exported from the top level provider...

from rebar3.

And should subcommands be able to depend on regular rebar3 providers? Or only their fellow subcommands?

from rebar3.

I've got it to

do(State) ->
    NewState = rebar_state:new(),
    NewState1 = rebar_state:create_logic_providers([rebar_prv_erlydtl_compiler], NewState),

    [TaskString | Rest] = rebar_state:command_args(State),
    Task = list_to_atom(TaskString),

    rebar_core:process_command(rebar_state:command_args(NewState1, Rest), Task),

    {ok, State}.

Which I'm looking to see what I can move (maybe everything) to the providers app itself.

from rebar3.

@oubiwann should we leave this open or close it? I'm just trying to not let open issues stick around forever even though they aren't really need :)

from rebar3.

Yeah, this can be closed -- the port is complete, it just won't live in the
rebar3 source :-) (as we discussed).

I'll close it, but will keep the branch for the work (linked in a previous
message on the ticket).

Thanks for all your work on the providers in support of community plugins!!

On Thu, Feb 19, 2015 at 9:37 AM, Tristan Sloughter <[email protected]

wrote:

@oubiwann https://github.com/oubiwann should we leave this open or
close it? I'm just trying to not let open issues stick around forever even
though they aren't really need :)

—
Reply to this email directly or view it on GitHub
#29 (comment).

from rebar3.