Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Add extension support to Mopidy #343

adamcik opened this Issue Mar 17, 2013 · 4 comments


None yet
2 participants

adamcik commented Mar 17, 2013

Looking at the current state of mopidy, specifically how factored out the the frontends and backends are from the mopidy core it has become clear that is is time to look at splitting out these from the main mopidy package. For now we will likely continue to have these in the same repo, but the basic idea is to make it easier for third parties to build on mopidy as we have already tried to do with the webservice frontend.

Based on the great plugin talk at PyCon 2013 I'm convinced that the right way to solve this is to use the entry_points feature directly from pkg_resources or the convince wrappers from stevedore. There is also support in pkg_resources for setting up a custom plugin dir and loading from that, but I personally think it is a bad idea, and that we should stick to just properly installed deps.

This would mean that we would create a mopidy-spotify package with something along the following in the setup.py, as withe the same for all the other cases.

    'mopidy.plugins': ['backend = mopidy.backends.spotify:SpotifyBackend]',

Given that the entry point format is name = some.module:some.attr [extra1,extra2] we could also have convention where name is one of frontend, playback, library etc. Which might be worth looking into to allow for even smaller more composable plugins. Alliteratively we could also allow the name to be an identifier without meaning, and use the extra1 to determine the plugin type. Or we could just have the plugin API written in such a way that they inspect/query them to determine what they can do. In this respect using the ABC clases might also be relevant.

For now this is just an initial brain dump to get this out there, more refinement of the plan for this will be needed. I also have an idea of prototyping this by making mopidy scan use plugins instead. This would basically allow us to split out the storage bit from the fetching of metadata etc.


adamcik commented Mar 17, 2013

We should probably also define some contrib/plugins module path the we support en encourage the use of. This also plays in on how we end up managing testing in this more complex setup.


adamcik commented Mar 17, 2013

Based on the idea of having a blacklist so we can do enabled if installed plugins, but allowing for explicit blacklisting to disable, I suspect we want to allow the plugins to choose the name in the entry point such that we have an identifier to use in the blacklist.

Other very important thing related to this change is making sure something like #342 gets done. As we will need to have some good tutorial for creating the plugins if we expect people to jump in and make them.


adamcik commented Mar 30, 2013

Other case that I would eventually like to add is an early hook for doing stuff like installing custom gstreamer elements. Though this would not need to be part of the initially supported feature set.

Also see http://docs.mopidy.com/en/develop/extensiondev/ for the start of our attempt to write the docs up front to get a better idea of how this should work for end users.


jodal commented Apr 1, 2013

With the merge of pull requests #372, #373, #374, #377, and #378 I consider extension support to be in a functional state and are closing this issue. Though, further refinements to the extension interface will happen as part of the config related issues targeted for v0.14.

@jodal jodal closed this Apr 1, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment