You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently, beets developers started documenting their python API. IMHO the web plugin is a bit clumsy (there are plans to improveit though) but maybe it makes sense to use the python API instead? This should also allow simplifications of the code base, e.g. the code in client.py could basically be removed then. Furthermore, it doesn't require users to start a separate services (beets web) to interface with beets from mopidy.
The text was updated successfully, but these errors were encountered:
Fwiw Integration with beets via Python API directly would tighten the coupling between mopidy and beets (which would potentially introduce maintenance problems down the road, e.g. conflicting python dependency versions) and prevent (re-)deploying beets independently from mopidy as well as accessing a remote beets library from within mopidy (e.g. see #3).
(The Microservice architecture is a common pattern for such a system and is already implemented by letting mopidy use beets via its web API.)
But personally, I would still prefer to stick to the (http-based) API, since I appreciate the possibility to decouple mopidy and beets on different hosts (as emphasized by @mgoltzsche).
(maybe I will finally manage to push myself into implementing #3 in the next weeks ...)
Recently, beets developers started documenting their python API. IMHO the web plugin is a bit clumsy (there are plans to improve it though) but maybe it makes sense to use the python API instead? This should also allow simplifications of the code base, e.g. the code in
client.py
could basically be removed then. Furthermore, it doesn't require users to start a separate services (beets web) to interface with beets from mopidy.The text was updated successfully, but these errors were encountered: