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

[Jonathan Maw <jonathanmaw codethink com>]

On 2017-07-07 14:10, Tristan Van Berkom wrote:
> 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 ?

I think the third approach is a good compromise. If an external project
is writing buildstream plugins, then naming the domains they use
<project>-<plugin> means that they won't have to worry about other
projects choosing a similar name and confusing people. There might still
be confusion because their element kinds collide, but that doesn't stop
the third approach being a good idea.