When Mopidy itself is installed via apt as system Python package, it requires any extensions to be installed on system level as well. Recent pip however requires the --break-system-packages flag for this to work. Moreover, most recent pip tries (and fails) to uninstall any module installed via apt to /usr/lib/python3, before installing same module to /usr/local/lib/python3.*. This can even cause failures with Python dependencies pulled by the mopidy package via apt, and such pulled by pip from PyPI when installing extension.
pip outside of venv/virtualenv/… is basically dead on any recent distro which offers Python packages with its own package manager.
Hence I do wonder whether there is any plan or idea to allow installing extension in a different way. Mopidy, as system package, does not see Python modules in any random venv. And calling Mopidy with the venv Python instance will miss its APT dependencies. Unless … with --system-site-packages it would have access to them. So maybe this would work:
But this does not look like something to cleanly implement into distro package.
Other projects like OctoPrint have internal plugin management, using an appropriate site to install plugins via pip, based on the Python environment it was called with. But that is very complex, and there were quite some issues with the site detection logic and with recent pip changes etc. Hence not something I would exactly suggest for Mopidy .
Easiest would be if there was somehow am optional way to tell Mopidy where to (additionally) look for extensions. Does Python have a native way to add additional import paths?
We’re aware of the issue with --break-system-packages, but we have sadly never decided on a new recommended way for how to work with a mix of extensions installed from distro and PyPI packages. It could be useful to start enumerating options, as I don’t know of any existing golden paths here.
That said, after maintaining Mopidy for 15 years, we have a lot less time on our hands to dedicate to the project. I prefer to focus my efforts on the Python codebase and leave packaging to others. Thus, I’d clearly prefer solutions where the Mopidy project just follows established conventions that makes life easier for distro packagers. Diving deep into building our own extension management systems to make mixing distro- and PyPI-installed extensions is far outside the scope we’re willing to take on.
It is possible to control where Mopidy looks for extensions by setting the PYTHONPATH environment variable (or site.addsitedir()). By installing extensions with pip into some venv and then use PYTHONPATH to make system-wide Mopidy find those, you’d be able to install PyPI packages without affecting any other system-wide Python programs, which is an improvement over --break-system-packages. (Note: This could still break the Mopidy installation, as PyPI-installed extensions could depend on packages that are incompatible with what Mopidy or distro-installed extensions depends on. To solve this fully, you’d need dependency resolving across distro- and PyPI-installed extensions, which is a bit much to wish for.)
.