On Mon, Apr 27, 2020 at 9:49 AM Jürg Billeter <
j bitron ch> wrote:
Hi Ben,
On Fri, 2020-04-24 at 14:48 +0000, Benjamin Schubert wrote:
> An example would be:
>
> project.conf:
>
> plugins:
> - origin: bst
> path: my_junction:plugins.bst
> sources:
> git: 0
> - origin: bst
> path: internal_plugins.bst
> elements:
> cmake: 0
I'm wondering whether we should define a new dict key instead of
reusing the `path` key to specify an element as plugin source. If so,
we could even implicitly infer `origin: bst` from the use of the new
key, unless we think that makes the format overall more confusing.
I like the idea of being more explicit, and by the sound of it, less verbose. As naming is hard (:-)), can you provide a sample snippet?
Now, seeing the syntax above, I would prefer to also have the convenience of saying in 1-2 lines: use all the plugins that are defined in this junction.
> kind: plugin
> sources:
> - kind: tar
> url: gitlab:bst-plugins-experimental/tree/master.tar.gz
As far as I can tell, `kind: plugin` elements won't contain anything
specific to plugin loading in their definitions. Could it make sense to
use the existing `kind: import` instead? This doesn't mean that we have
to support arbitrary element kinds as plugin sources (as other elements
would have to be built), however, it would mean that users don't have
to learn about another special element kind.
I don't think it hurts to have a 'plugin' kind even if it currently would do the same as the import plugin. It makes them easily identifiable.
> Any comments, suggestions, problems?
> Does anyone foresee any problems that this would bring with regard to
> remote execution?
Element plugins are always handled locally, so I don't expect this to
cause any problems with remote execution.
I think the question was meant to include the Remote Asset API. Also in that case, no, I don't think there would be any problems. Actually, I think it would consolidate the plugin fetching with the source fetching, and if everything is already tracked, you would only be hitting CAS for their content.
Cheers,
Jürg
Cheers,
Sander
