I’ve been thinking about making an open source application in Elixir that would benefit from having extensibility from third parties. So the user of this application would download a compiled release, run it and decide “I want the last.fm scrobbler extension” and I want them to be able to bring in a bunch of modules by providing the files as a zip or whatever archive makes sense to the application.
This isn’t PHP, we can’t just drop them in a folder. But my first thinking is simply that the application compiles the new code and saves some config info to make sure it will be loaded on subsequent starts. It will not be part of the release but it will be part of the “installation”.
Does this make sense? Should I consider some alternate approaches?
I’d rather not make users compile the application source + their extensions beforehand as it would defeat many of the benefits of distributing ready-to-run binary releases.
You can load extensions in real-time without issue. What I’ve always done is just add the compiled applications to the same library release (so they get loaded, or you can explicitly load from a path too, I’ve done that before as well), then just set the module entrypoint for it in a configuration (application environment), or if it’s a running system then just tell it to load it straight and it can register itself in and is immediately loaded and doing its work.
As long as it’s in the load module path (which you can alter) and ‘something’ loads the entry module for the plugin (configuration files are great! or a database or whatever to get the names) then it all just works. You could even scan all beam files in the module paths for what implements a certain behaviour and load those as well (dynamic loading! I’ve done that before as well, though I like configs a bit more in ‘most’ cases, more control).
Just have to make sure the plugin is compiled with the same version as everything else, a simple build API fixes that up.
Or you can even load plugins as their own nodes that connect to the main system and register themselves in too, that’s fully under the plugin control then, no dynamic system needed.
Lots of good notes here. But am I following you in that you are talking about compiling the plugins before hand? I was thinking about the core application being distributed as a binary release while plugins might be source-based. Then again, that causes potential trouble with plugin dependencies I guess. Just a bit more work to either offer compilation for plugin creators or making them build for multiple architectures. In that sense source and compiling at run time felt promising. Assuming those facilities are there in a release.
So, some further reading makes me think a compiled Beam file would be platform independent, but as you were saying I would need to make sure to match up the versions that things are built with, not per platform, just Elixir, Erlang + OTP if I got things right.
You can of course compile on demand, but you need to be sure to include the compiler libraries, and you wn’t have mix available unless you include that as well, which will generate how code can be generated as it won’t think it’s a full release then.
But yeah, compiled beam file’s are platform independent, but they are dependent on the OTP version (and to a lesser extent the Elixir version) that they are compiled with.
