intermittent failure to load correct plugin when a local plugin is a subclass of existing plugin

[Mike McCracken]

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.

[Sergio Schvezov (sergiusens)]

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()

[Mike McCracken (mikemc)]

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

[Sergio Schvezov (sergiusens)]

El miércoles, 24 de agosto de 2016 23h'34:56 ART, Mike McCracken
<email address hidden> escribió:
> 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.)

In fear of deviating from the original bug topic I share this:
http://snapcraft.io/docs/build-snaps/plugins

--
Enviado con Dekko desde mi dispositivo Ubuntu

[Mike McCracken (mikemc)]

heh, thanks again - apparently I'd searched for 'local' on that page
instead of 'custom'.
d'oh!

On Thu, Aug 25, 2016 at 6:54 AM, Sergio Schvezov <<email address hidden>
> wrote:

> El miércoles, 24 de agosto de 2016 23h'34:56 ART, Mike McCracken
> <email address hidden> escribió:
> > 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.)
>
> In fear of deviating from the original bug topic I share this:
> http://snapcraft.io/docs/build-snaps/plugins
>
>
> --
> Enviado con Dekko desde mi dispositivo Ubuntu
>
> --
> 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
>

[Sergio Schvezov (sergiusens)]

local plugins in newer snapcraft are now different