Elixir integration, escripts, and build tools madness
arkgil opened this issue · comments
So I really wanted to make it possible to write plugins in Elixir - I hoped this way we could encourage community to get involved and try to extend EPL.
I thought to myself: "Ha! Since Mix can build Erlang projects, that's gonna be piece of cake. I'll just add umbrella mix.exs, and EPL's own mix.exs and everything should work like a charm".
It did and it compiled. Mix could even share dependencies with rebar in the same directory so no garbage was produced except different directory for compilation artefacts. But we can live with that.
Wait, did I forget anything? Riiiight, we need to build an escript. Which is currently built using hacks probably found on the Internet by Michal during his university years, sprinkled on top with black magic. It looks like it just loads all beam files and contents of all priv directories it can find, reads them (!) and writes them to zip file (!!!). Apparently prepending all this stuff with escripts shebang makes it a working escript.
I thought to myself once again: "Hmm, if Mix is such a cool build tool for such a cool language, it probably can build escripts, right?". And indeed it can. It can even build escripts for Erlang applications, with or without Elixir included. "Phew, problem solved **(wiped forehead)**". But...
Mix can't package priv into escripts. So with our current setup there is no way to build an escript with Elixir using Mix. We can't use our current method too, because that would require compiled Elixir to be present in our build directory, and I'm pretty sure rebar won't handle Elixir compilation.
In my opinion the only viable and should-be-working option is to allow users to pass path to their Elixir installation ebin directory, so that we can package it manually in bootstrap script. Once packaged we would need to optionally start it in erlangpl.erl and probably log a message if we couldn't do that.
I wrote that all because I hoped for rubber-duck-like inspiration and it worked. I figured out last paragraph while writing.
But as always I need opinions, so comments and feedback are welcome.
Great issue description
I really hope for Elixir plugins because I know something about Elixir and I wrote very simple things in it. It's easier for me. And I know almost none about Erlang
Another thing, somehow related to this issue is erlangpl-ui include method. Right now we're using git submodules but maybe there is better way for doing that.
I very much like the idea of documenting the whole thinking process accompanying issue creation. It gives more context to the problem you are trying to address and therefore it gives others an opportunity to contribute with more meaningful feedback.
I think we can assume several things and maybe it will make your work easier:
- Erlang and Elixir are installed on the machine from which one runs the ./erlangpl script
- Elixir plugins are structured as regular Erlang applications, e.g. have ebin/*.beam, priv/ and ebin/name.app
- Elixir applications are built with mix and so we can hardcode their path the same way deps/ and apps/ are hardcoded in the bootscript
Does it help?
BTW, the bootstrap script is heavily inspired by rebar.
I don't think there would be a problem with creating Elixir plugins. The only issue I saw was including Elixir runtime in erlangpl escript, so that anyone can download it and get started quickly with their own plugin.
What is everyone's opinion on including Elixir as a part of our standard distribution? This could be done by providing path to local Elixir installation when running bootstrap (anyone could build it this way). Additionally path to Elixir could be given to erlangpl script, so that if anyone wants to experiment with newer version of Elixir, overriding embedded version will be easy (I assume that prepending the code path will override anything embedded in escript).
Starting Elixir could be made optional, so that if anyone forgets to include it, he'll just get a warning (maybe he wants a lighter version of a script).
This approach has a couple of advantages:
- we don't care where Elixir is installed - just give us the path
- we don't have to manage two build tools in one project (just rebar without Mix)
- including Elixir will be optional (unless we agree to include it with standard distribution - but I guess it's gonna happen when we have core plugin written in it)
.. and I really can't think of disadvantages, so please, comment!
I was actually thinking about trying to move the project to rebar3 for a similar reason (make it easier for people to contribute). I wonder if that would make the Elixir integration easier.
That said, I think @arkgil is right with the approach.
I've sent PR, please review!
Aaand it's merged. We have Elixir support in master now
I think we can add info about writing plugins to README or maybe we should wait for UI plugins to have full support.
Cool. So I'll try to focus more on UI part then.