Don't try to initialize ABCs that inherit from BeetsPlugin or MetadataSourcePlugin

[amogus07]

Problem

Running this command in verbose (-vv) mode:

$ beet -vv --plugins=vocadb version

Led to this problem:

user configuration: /home/konstantink/.config/beets/config.yaml
data directory: /home/konstantink/.config/beets
plugin paths: ['/home/konstantink/dev/src/beetsplug/more', '/home/konstantink/dev/src/whatlastgenre/plugin/beets/beetsplug', '/home/konstantink/dev/src/beets-fetchartist/beetsplug', '/home/konstantink/dev/src/beets-stylize/src/beetsplug']
Loading plugins: vocadb
** error loading plugin vocadb
Traceback (most recent call last):
  File "/home/konstantink/.local/share/uv/tools/beets/lib/python3.13/site-packages/beets/plugins.py", line 448, in _get_plugin
    return obj()
  File "/home/konstantink/.local/share/uv/tools/beets/lib/python3.13/site-packages/beetsplug/vocadb/abc.py", line 155, in __init__
    user_agent=USER_AGENT, base_url=self.api_url, logger=self._log
                                    ^^^^^^^^^^^^
AttributeError: 'PluginABC' object has no attribute 'api_url'
Sending event: pluginload
library database: /home/konstantink/.config/beets/library.db
library directory: /home/konstantink/Music
Sending event: library_opened
beets version 0.0.0
Python version 3.13.5
no plugins loaded
Sending event: cli_exit

Here's a link to a plugin that triggers the bug: https://github.com/prTopi/beets-vocadb/tree/demo

The bug is that beets tries to instantiate an ABC exposed by a module in a package under beetsplug because it inherits from beetsplug. Even though it's is only triggered by specific plugins, I still think it should be fixed within beets. In the latest commit, you can see my current workaround being reverted for demonstration purposes. I don't think it should be necessary, beets shouldn't be trying to initialize ABCs. Another solution could be restricting the location of plugin classes, only loading plugin exposed by the module or package directly under beetsplug and ignoring modules or subpackages within packages. Even better would be a combination of both.

Update:

Apparently, beets does check for abstractness, but classes without abstractmethods aren't considered abstract in Python.

Setup

• OS: Fedora
• Python version: 3.13
• beets version: 2.5.0
• Turning off plugins made problem go away (yes/no): yesn't (no more error but still unintended behavior within beets)

My configuration (output of beet config) is:

plugins:
- vocadb

[semohr]

Strangely enough we have a check if the class is abstract and should skip it, see here.

I agree tho. Very fun to me that this comes up now, after we had a very long discussion about this quite recently. There is still the #6034 open which should allow you to define all plugins you want to expose in __all__. This should prevent the issue, right?

[amogus07]

Strangely enough we have a check if the class is abstract and should skip it, see here.

It seems inspect.isabstract only returns True for ABCs with at least one abstractmethod. My class only has "abstract" attributes that aren't initialized anywhere except in __init_subclass__.

I agree tho. Very fun to me that this comes up now, after we had a very long discussion about this quite recently. There is still the #6034 open which should allow you to define all plugins you want to expose in __all__. This should prevent the issue, right?

Yes, not sure if it's the best solution though.

[semohr]

I'm open to other suggestions, but I don't think the way you use abc in your plugin is easily detectable. The underlying issue is that two plugins are exposed from one module, which should not happen and is not detected by beets (yet).

[semohr]

Another solution could be restricting the location of plugin classes, only loading plugin exposed by the module or package directly under beetsplug and ignoring modules or subpackages within packages. Even better would be a combination of both.

We had this discuss before and I think we want to allow re-exporting plugins. It shouldn't really matter where you define a plugin as long as it is exposed from the module. We would break some plugins if we restricted this e.g. re-export in beetsplug/awesomplugin/__init__.py from a beetsplug/awesomplugin/plugin.py file.

[amogus07]

I considered adding an empty dummy abstractmethod to PluginABC and overriding it in __init_subclasss__. That works at runtime, but basedpyright isn't able to evaluate __init_subclass__ statically, causing it to think I didn't "implement" the abstractmethod wherever I subclass PluginABC

[snejus]

We need to ask ourselves 'how has this been working fine before?' and we will find that the fix is surprisingly simple. Which makes me think that maybe it was actually designed to work that way (but it lacked any explanatory comment, so I adjusted it).

See #6100