Hi there, we are working on a habitat package for the Janus WebRTC proxy, which is a service that supports native plugins. There is a central “janus.cfg” file which configures the server to point to:
- A plugins folder
- A config folder for plugins
To install a plugin, you copy your plugins binary into the plugins folder, and the plugin’s configuration file into the config folder for plugins. Janus only supports a single folder for plugins and a single folder for plugin configs. Each plugin can have its own config file. For example, the plugin “foo” would have a “foo.so” file dropped in the plugins folder, and a “foo.cfg” file dropped into the plugins config directory.
For the main Janus package, we’ve set things up so the plugins folder is in {pkg_path}/plugins and the plugins config folder is just {pkg_svc_config_path} since the plugin configs can be set at the service group level.
This works fine if the plugins we want to support are included in the main Janus package, since we can bundle the configuration templates and the binaries into the package. However, we are working on a custom Janus plugin (that should be considered 3rd party from Janus’s POV) and would like to be able to install this plugin via its own habitat package.
It seems habitat is fundamentally not designed for this workflow, since our separate plugin package would need to come with its own configuration template, but is not a service. It also seems ugly if we need to install binaries from our plugin package into the plugins folder for Janus, which is managed by the Janus package.
In order for a “plugin package” to work, it would need to be able to do two things:
- Install (and uninstall) files “on top” of an existing package’s installation directory (in this case, into the plugins folder of the Janus package)
- Introduce additional TOML and configuration file templates into an existing package’s service group(s)
Is there any obvious way to do this right now? If not, what would be the best way to proceed?