Rebuild boot script with modular architecture about exrm

[alco]

Sourcing all plugins could prove problematic sooner than later.

Have you considered an inverse approach? Similar to how git commands work. Git has core commands that are shipped with it. In addition, it can search the $PATH for executables that match git-* and they can be run as git <external command name>.

The reason I call this approach inverse is that instead of sourcing everything into the core script, you will run each external script separately, possibly sourcing in some core functionality common to all scripts.

Using this architecture, the core set of commands could be made rather granular, so that plugin commands would be able to call specific ones at different points in their execution.

[smpallen99]

I have not come across any need to a boot script yet that must be executed as part of the elixir/erlang install. I do have scripts that run during installation, but since I package in an rpm, I have the capability to run scripts with it.

Do you have any examples?

BTW, I like @alco's suggestion...

[bitwalker]

@alco I like that approach a lot better. What would be the approach for getting common functionality sourced into the plugins? I suppose since the plugins would live in a predictable location of the release bin directory, they could just source the core script via relative path.

I suppose the idea here then would be that all of the individual boot tasks that already exist would be extracted in to plugins, and the boot script would be pared down to just looking up the plugin script for the requested command? Yeah, definitely a fan.

@smpallen99 The example I used above of how conform is executed in the boot script prior to commands which start the app is a good one. Basically I'm using environment variables set up in the prelude of the boot script from a custom function, which will compose and execute the command to convert .conf/.schema.exs files to a final sys.config on boot. Right now this stuff is injected into the body of each command's handler. It would be nice if I could keep the boot script free of custom stuff like that, and make it general enough so that other plugin authors could offer similar functionality if needed. Perhaps my case is the only one which needs it, but I kind of doubt it.

@alco Speaking of the conform example, how would that be accomplished with the git-like architecture? Since conform needs to run anytime the VM is booted, I could perhaps accomplish it by making the app start commands part of the core functionality, and just include the conform stuff there, but I would like it if I could pull it out as some kind of plugin.

Thanks for the thoughts guys!

[alco]

Multiple approaches are possible depending on how granular or powerful you want plugins to be.

I can imagine two structures.

1. Have a common setup in the boot script and then exec a plugin:

# boot.sh
export SOME_VAR=...

function some_func() {
}

plugin=${1#boot-}
shift 1
exec plugin_dir/$plugin $@

# boot-plugin1

# do something here, can call other plugins
# not sure exactly how though

$ ./boot.sh plugin1

With this approach, composability comes with the ability for plugins to call other plugins.

2. Use hooks for plugins

# boot.sh

# do some setup

# call all scripts that have registered for "post-setup" hook
call_hooks "post-setup"

# prepare command invocation
# ...

call_hooks "pre-command"

# run command
# ...

Here you let plugins to register for certain steps on the way to executing the requested command. The commands themselves can still reside in separate scripts allowing for 3rd party commands to be added.

I can't say at the moment how the core state will be shared with multiple plugin or hook invocations. Perhaps looking at Git's source could shed some light on it.

[bitwalker]

I'm going to tentatively close this for now. At the time I wanted to build out our own bootscript, but I'd rather try to maintain some parity with relx's boot script for maintenance. If this becomes a common request, we can revisit it then.