Comment 1 for bug 1616656

Revision history for this message
Sergio Schvezov (sergiusens) wrote : Re: [Bug 1616656] [NEW] intermittent failure to load correct plugin when a local plugin is a subclass of existing plugin

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