Re: [BuildStream] Thoughts around plugins: deprecation

[Daniel Silverstone <daniel silverstone codethink co uk>]

On Mon, Dec 03, 2018 at 21:18:11 +0900, Tristan Van Berkom via BuildStream-list wrote:
> > > 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).

Yes, the only reason I included project names in the plugin path scheme was to
allow a consuming project to refer to a plugin chosen by a junctioned project.
E.g. to allow project A to junction in project B and then use B::fooelement as
an element plugin.

> 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.

Yes, that'd also be useful and requires at minimum disambiguation by project
name.

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

I think, if you're in the middle of a known transition, you may want to silence
the warnings during the conversion so that they don't become noise you
automatically ignore.

E.g. If I know that I'm transitioning from a deprecated git plugin from source
A to the new one in source B, I want to silence that warning, but still see if
a project I junction in depends on a deprecated bar plugin from source C.

Ultimately this is a nice-to-have and I'd be prepared to drop the desire to
silence deprecation warnings.

D.

-- 
Daniel Silverstone                          https://www.codethink.co.uk/
Solutions Architect               GPG 4096/R Key Id: 3CCE BABE 206C 3B69