Re: [BuildStream] Thoughts around plugins: deprecation

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

Hi,

On Mon, 2018-12-03 at 11:24 +0000, Daniel Silverstone via BuildStream-list wrote:
> On Fri, Nov 30, 2018 at 15:03:26 -0500, Chandan Singh wrote:
> > > I was thinking that, in order to be able to silence a deprecation warning we
> > > need to be able to address the specific plugin it comes from.  Since during the
> > > migration from one plugin to another (across repos) there may be a time when
> > > more than one plugin has the same *basename* it's necessary to be able to
> > > address them within their particular sources.
> >
> > I see. I was hoping that we'd be able to derive this information
> > implicitly. Since a given project cannot use two plugins withe same
> > name, and we would know which project the element (and hence the
> > warning) came from, shouldn't we able to say something like "source
> > FOO from project BAR is deprecated" ? This would mean that the
> > deprecation warning would appear once per project when a project has
> > junctions. If that is acceptable, then we may be able to avoid this
> > new logic about names and paths. What do you think?
>
> Personally I worry that within a project it might be necessary to have multiple
> plugins of the same name during a transition period.  I suppose an alternative could
> be to allow the import of plugins to rename them, e.g.
>
> ```yaml
> plugins:
>   - origin: whereverwemovepiptoo
>     elements:
>       pip:
>         version: 0 
>         rename: newpip
> ```
>
> Would that sit better with you than a complex new naming scheme?

I wonder if there is some confusion here, I am having a hard time
digesting this part of the conversation.

Whether it becomes possible to have multiple plugins with the same name
existing within a single project, does not have any baring on
junctions, junctions are windows to *separate* projects, and each
project is already a separate namespace for inclusion of their own set
of plugins (already today, the same plugin name can be used, and have a
different meaning, in separate projects loaded in the same pipeline).

What I do understand, is that there is a desire to explicitly silence
deprecation warnings, and a toplevel project might want to silence a
deprecation warning about a deprecated plugin being used by a
junctioned subproject; in which case the junction name would be needed
in order to address the plugin used by a subproject.

I am unsure however how important it is to be able to silence
deprecation warnings.

Cheers,
    -Tristan