(background)
Hello, I recently installed Mopidy and Snapcast. When installing, I elected to use the repository method which does not support pip unless you set up venvs, and is limited to the repo packages like mopidy-mpd, mopidy-beets etc. It seems that mopidy-iris is not available, however I did get an otherwise functional mopidy/snapcast installation.
After exploring a dozen outdated and/or nonfunctional Mopidy clients (also after trying to install Iris and giving up) I realized that most things out there simply don’t work. I read the installation instructions for Iris and have found them to be lacking.
Some questions and observations:
I thought running it inside docker would be simple ad make sense. Iris is a client right? Well following the docker instructions (and stripping out extra stuff I don’t need) it appears that the docker image is not just iris, but a fully packaged version of Mopidy as well. If I’m not mistaken, this feels like quite a bit of scope creep, having to install a complete Mopidy + Mopidy-iris installation when I already have a fully functional Mopidy instance ready. Q: Is it possible to install and run ONLY Iris? I was expecting a service or files I could drop into a web root, then point at an existing Mopidy instance via some config files and be done with it.
What’s with the manual installation instructions? Per the .md:
A. Clone the code base, okay easy enough
B. Run a python install script. Got it, not sure what this does but done
C. Run a script as sudo that allows Mopidy to run the installer. This requires a “path to Iris”. Uhh…I don’t have a path, I’m trying to install Iris. So maybe this whole git repo should be under /var/www and I run apache/nginx? Or maybe the dist folder gets copied into Mopidy’s folder somewhere? This is…unclear and despite experimenting, I got completely stuck here.
(edit: I’ll redact this point, I was being lazy) There is also a pip option, but again that is incompatible with the repository installation method.
So that’s where I’m stuck. I hear that Iris is great, but the installation docs are either unclear, or contain (IMHO) extra bloat. I expect Iris to be a standalone application and/or some sort of hostable web platform, either of which should connect to Mopidy, not fully bundle it.
Thanks in advance for everyone who works on this, any direction or clarification is appreciated. The simplest and cleanest way to see this resolved would be if Iris was to be re-included in the Debian packages, as it used to be provided as mopidy-iris. If that is not possible, then clarification of how to “properly” install, or cleaning out the docker image to provide just Iris, with an option to bundle it with Mopidy would be nice.
Iris is a Mopidy extension, meaning it has to be deployed within Mopidy server (and its HTML content will be served by Mopidy server).
But why are you saying a pip installation of Iris is incompatible with the use of packages for Mopidy?
There’re other extensions not available as DEB packages and AFAICT it’s common to install them through pip even if Mopidy was installed through packages…
Re: Deployed within Mopidy Server
Yes, that is what I would expect, however the problem I had mentioned is the docs mention running the last command with the path to iris, but without it being installed (or listed in documentation?) I’m unsure where to identify this. Perhaps it’s just a minor phrasing issue.
Re: Incompatible
Yes, you make a good point. It’s not fair for me to call it incompatible, let’s chalk that up to me being lazy. The exact problem is that pip installations throws an error saying that python is externally managed or something like that, with a suggestion to set up a virtual environment to use pip modules. So yeah, that would likely be a solution, and me in my laziness/inexperience with python venvs didn’t want to take a crash course on the topic for one module. But that’s my problem, not a fault of the mopidy/iris team, so I’ll redact that statement.
Make your life easier! Install Iris through pip with--break-system-packages. Later then you’ll learn about virtual envs and contribute a new installation process using a virtual environment.
You can also try Argos, a client that is not bundled as an extension and is available as a DEB package. Supposed to be maintained, Bug reports welcome! See Releases · orontee/argos · GitHub
As @Matthias_Meulien said, --break-system-packages will fix this. Our documentation is outdated w.r.t this.
Could you point out which of the clients at Extensions are no longer functional, some of them do go rusty as their maintainers become busy elsewhere. If you highlight specific problems we can try and address them
I ended up getting it to work, indeed with the --break-system-packages option, on a fresh install. I realized that one thing I had missing on my initial install was configuring the mopidy-web extension. I guess I just assumed that the extension knew how to make itself work, but it seems that without configuring it, no web interface is available. It seems obvious in hindsight, but I think I was starting with a blank mopidy.conf and never added that config to it.
Lesson learned, my second install (aside from some unrelated complications) is much cleaner and has a functional Iris instance running. Thanks for the pointers!
I can’t recall any broken clients off the top of my head (I tried a bunch and it was a week or so ago) but I also can’t claim that it wasn’t related to an incomplete or partially broken installation either.
Starting with a blank mopidy.conf is 100% the right way to go. Just add the bits you need, often it’s only a few lines. I assume in your case you’re talking about the http/hostname setting e.g.
[http]
hostname = ::
We have to apply restricitve settings by default. Glad it’s all up and running.