Comment 2 for bug 1616656

Thanks for the workaround.

I'd be fine with any naming convention as long as it was documented.
(BTW, speaking of docs, it was hard to tell where to put the local plugin
relative to the snapcraft yaml - I had to add a print to the snapcraft
source to see where it was looking. I didn't find any documentation
covering local plugins.)

On Wed, Aug 24, 2016 at 3:54 PM, Sergio Schvezov <<email address hidden>
> wrote:

> El 24/08/16 a las 19:26, Mike McCracken escribió:
> > Public bug reported:
> >
> >
> > I have a local plugin called 'perlmake' that is a subclass of the
> > MakePlugin class. It calls "perl Makefile.PL" to generate a "Makefile"
> > before running super().build() to do the 'make' calls.
> >
> > My snapcraft.yaml has one part that uses my plugin subclass.
> >
> > snapcraft build will (not always, but more often than not) pick the
> > MakePlugin class instead, meaning that the build breaks because
> > there's no Makefile generated.
>
> Yeah, this is a known issue.
>
> > This is due to logic in pluginhandler.py, where _get_plugin() looks
> > for the first thing in the vars(perlmake) dictionary that is a
> > subclass of BasePlugin but isn't BasePlugin itself. This ends up
> > sometimes being MakePlugin instead of my PerlMakePlugin. I need to
> > import MakePlugin to subclass it, so this method of finding the plugin
> > class isn't reliable.
> >
> > In my case I will just reimplement the rest of MakePlugin, but it
> > might be worth fixing _get_plugin for future use. Perhaps we could
> > allow a module-level variable like PLUGIN_CLASS, which I could set to
> > PerlMakePlugin and _get_plugin could check that first, if it exists.
>
> No need to, don't import the symbol/class (from snapcraft.plugins.make
> import MakePlugin) but instead import the module (from snapcraft.plugins
> import make) and subclass it with make.MakePlugin.
>
> This is indeed a workaround. We are exploring options though and
> suggestions are welcome (simple one would be with naming convention of
> plugin-name == (module-name + 'Plugin').lower()
>
>
> ** Changed in: snapcraft
> Status: New => Triaged
>
> ** Changed in: snapcraft
> Importance: Undecided => High
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1616656
>
> Title:
> intermittent failure to load correct plugin when a local plugin is a
> subclass of existing plugin
>
> Status in Snapcraft:
> Triaged
>
> Bug description:
>
> I have a local plugin called 'perlmake' that is a subclass of the
> MakePlugin class. It calls "perl Makefile.PL" to generate a "Makefile"
> before running super().build() to do the 'make' calls.
>
> My snapcraft.yaml has one part that uses my plugin subclass.
>
> snapcraft build will (not always, but more often than not) pick the
> MakePlugin class instead, meaning that the build breaks because
> there's no Makefile generated.
>
> This is due to logic in pluginhandler.py, where _get_plugin() looks
> for the first thing in the vars(perlmake) dictionary that is a
> subclass of BasePlugin but isn't BasePlugin itself. This ends up
> sometimes being MakePlugin instead of my PerlMakePlugin. I need to
> import MakePlugin to subclass it, so this method of finding the plugin
> class isn't reliable.
>
> In my case I will just reimplement the rest of MakePlugin, but it
> might be worth fixing _get_plugin for future use. Perhaps we could
> allow a module-level variable like PLUGIN_CLASS, which I could set to
> PerlMakePlugin and _get_plugin could check that first, if it exists.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snapcraft/+bug/1616656/+subscriptions
>