Re: Revisions Draft RFC [Re: Proposed public data fields for dpkg build and deploy elements]

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Fri, 2017-07-07 at 13:42 +0100, Jonathan Maw wrote:
> On 2017-07-07 10:36, Tristan Van Berkom wrote:
[...]
> Hi Tristan,
>
> Do I understand correctly that this means that all plugins in the 
> buildstream
> repo will use the "bst" domain (hence public data version numbers from 
> main
> buildstream format), and that domains other than "bst" are for external 
> plugins
> (and use external plugin format versions)?

This is a bit up for grabs, there are two plausible approaches:

1.) The "bst" domain is only for public data that is understood
    directly by the core BuildStream library.

    For instance currently both "integration-commands" and
    "split-rules" have some support in the core apis
    Element.integrate() and Element.stage_artifact().

    In the same vein, with this approach one could justify
    adding public data definitions to the "bst" domain if they
    are considered general purpose enough to be useful to various
    plugins with the same underlying definition and syntax.

2.) The "bst" domain is strictly the domain for every and all
    elements that are first class citizens in BuildStream itself.

    I.e. elements maintained in the BuildStream code base.


The first approach is generally nicer for some reasons:

  o Documentation would be better readable, rather than having very
    dpkg related stuff in the main public data documentation, that
    documentation would belong in the consuming dpkg-deploy element
    documentation instead.

  o In a scenario where for instance, we have a separate incubator
    repository for plugins which dont quite cut it yet, are not
    API stable yet and are not mainstream enough to include into
    BuildStream proper, then when an element moves from that
    incubator repository into BuildStream proper, we would not have
    to change the public data domains; so projects already depending
    on third-party-but-now-first-class would have an easier migration
    path.

The second approach is a bit more bullet proof because:

  o There is little or no chance of namespace collision; people
    explicitly choose which plugins they use outside of buildstream
    and those elements as a matter of convention, never use the
    "bst" domain for public data; and BuildStream first class plugins
    never use a domain other than "bst"

A third approach might be to say that first class BuildStream plugins
which declare public data that is very element specific, still use the
"bst-" prefix for their domain names, this would have some of the
advantages of (1) while keeping the bulletproof nature of approach (2).

I know we casually discussed that it might be (2), but I'm leaning
towards preferring (1) honestly (or maybe the last approach with a
"bst-" prefix).

But I can be persuaded if there are any strong feelings or arguments
for a given approach... Thoughts ?

Cheers,
    -Tristan