Re: [BuildStream] Thoughts around plugins: deprecation

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

On Mon, 2018-12-03 at 16:03 +0000, Daniel Silverstone via BuildStream-list wrote:
> 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.

Interesting, I have focused so much on clear separation, and making
sure that using another project's plugins would never happen
accidentally, I never considered whether going through another project
to explicitly load a plugin would be desirable.

Now that I think of it, it seems that we don't need any "feature" to
achieve this kind of sharing, project B can very well put their plugin
definitions into a file to be included by their project.conf, project A
can then cross-junction include the plugin definitions of project B.

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

Honestly I don't feel super strongly about it, not doing something
until we really must is usually a good strategy, though.

Cheers,
    -Tristan