Support for LiquidJS plugins

[mmomtchev]

I am thinking about moving the npm install option parsing from ad-hoc code in meson and the conanfile.py to a specialised LiquidJS plugin. It will read the npm_config_* variables, it will read the config section in the package.json and then it will generate strings with the command-line options for meson and conan. This will remove lots of custom code exposed to the end user and it will provide a single centrally managed configuration tool.
LiquidJS has already very good support for plugins, the only thing missing is some custom item in the xpm part of the package.json that auto-loads the listed plugins. Currently there is no way to register a new helper or a plugin in the engine?

[ilg-ul]

I am thinking about moving the npm install option parsing from ad-hoc code in meson and the conanfile.py to a specialised LiquidJS plugin.

I don't know what are the specifics of your use case, but, at least in my intensive use of LiquidJS, it is a very nice template engine and less a configuration tool.

It will read the npm_config_* variables, it will read the config section in the package.json and then it will generate strings with the command-line options for meson and conan.

Yes, this sounds like a configuration tool.

LiquidJS has already very good support for plugins, the only thing missing is some custom item in the xpm part of the package.json that auto-loads the listed plugins.

I have no experience with LiquidJS plugins. What do you need to do to install them?

Currently there is no way to register a new helper or a plugin in the engine?

No, in the xPack design, managing dependencies and build steps (done by xpm) is distinct from managing configurations (done by xcdl).

Do you have an example of such helper?

[mmomtchev]

Yes, it is a configuration tool that generates a string (the command line options for meson and conan), which means that it can be implemented as a LiquidJS filter.

LiquidJS supports custom filters - which you already use:

const engine = new Liquid();
engine.registerFilter('uppercase', x => x.toUpperCase());

or plugins which is simply a require that calls a user script that can call registerFilter itself (eventually with multiple filters):

const engine = new Liquid();
engine.plugin(require('./up.js'));

with up.js containing:

module.exports = function (Liquid) {
    this.registerFilter('uppercase', x => x.toUpperCase());
}

This would allow a package to easily extend xpm. The filter can do everything - it can receive an argument and must return a string.

The other option would be to make a wrapper that xpm will launch and which would launch the conan/meson process itself, but this comes with the usual Windows/UNIX problems.

[ilg-ul]

So, what you basically suggest is to have a configuration property in package.json, to define an array of strings, that are imported and passed when creating the engine?

At a second thought I'm not sure that this is realistic, for this to work the packages with the plugins must already be available in node_modules inside xpm.

For this to work, xpm must run an internal npm install ... at each invocation, which is not exactly a joy.

[ilg-ul]

The alternative would be a CLI tool that generates the JSON output and the build uses preparsed files.

Can you give me an example of what information you need from those tools, and, once available as custom properties to LiquidJS, how would you use them to configure xpm actions/buildConfigurations/etc?

Personally I still doubt that this is a good idea.

I would use a CLI tool to generate files that are directly used by meson/conan, and avoid the LiquidJS plugin or a separate JSON file.

[mmomtchev]

Liquid is still initialised the same way for all commands. The only thing that changes is that the path is configured before Liquid is invoked to render the templates.

[ilg-ul]

Yes, but let's assume that you already wrote the plugin and xpm allows to use it. Can you give me an example of how you would use the new properties/tags implemented by the plugin in the xpack property of package.json?

[mmomtchev]

I have a plugin that generates options for meson and conan respective formats reading their possible options from the introspection and the passed values from the npm_config_* environment variables and producing -Dopt=value or -o opt=value strings like this:

"conanInstall": "conan install . {% conanOptions %}"

conanOptions being the custom tag that refers to the plugin.

[ilg-ul]

So this is a one time use of the custom tag, during project setup.

In this case I would write a small JS code, called for example conan-install.js to do exactly what you said, get the configuration options and invoke conan.

In this way you will not add the plugin overhead to all xpm invocations, plus that you'll have full and easy control on all options.