Mopidy 3.0 released

We released Mopidy 3.0 yesterday. It no longer supports Python 2.7, but instead requires Python 3.7+.

You can read more here, with links to all the details:

1 Like

Congratulations to the mopidy team! Thanks to you all for your work on this, and for keeping the project alive post python2.

[tips for new players]
I’ve managed to get the new version installed and running on Armbian Ubuntu Bionic. The Mopidy-Local and Mopidy-MPD plugins seem to run, too.

No problems with Mopidy-Local scanning my library…

INFO     2019-12-25 03:26:39,183 [20489:MainThread] mopidy_local.commands
  Scanned 18687 of 18687 files in 10146s.

Getting this far was a non-trivial exercise, mainly due to Bionic using python3.6.9 by default. It is possible to get python3.7.5 installed (apt-get install python3.7) … however … the python3-gst-1.0 packages available for Bionic do not include a version that works with python >= 3.7. The packages built for eoan (1.16.1-1) seem to work, if you update all the dependencies. The trickiest dependency to update was libstdc++6-9.


Why is it python3.7? What features of Python 3.7 are used by the mopidy? This will make hard for peapole to use mopidy since there are major Linux distributions that does not support python3.7 yet, like Ubuntu 18.04.

Ubuntu 18.04 (and derivatives of that) is the only OS that doesn’t support Python 3.7 by default, and that’s because it’s rather old now. Ubuntu 20.04 LTS is due out nearly next year. Our choice of 3.7 is deliberate and I agree it’s the right one going forward.

The version of python3-gst-1.0 from 19.04 (disco) should be sufficient. I think the one from 18.10 (cosmic) should also suffice but the Ubuntu site seems to be having issues with that info right now. I’m working on a FAQ which addresses some of these questions. But it’s Christmas so it will have to wait.

Also note the release is still very fresh so we don’t have updates for the Debian packages yet. There will be instructions for upgrading when this is all ready.

@jodal has done a fantastic job getting this altogether. The transition has been a long one but the project’s future looks bright. Thanks @natumbri for your kind words.

1 Like

FWIW, python3.7 seems like the right choice to me, too.

The point of the second part of my post was to demonstrate that even on Armbian Ubuntu Bionic - a corner case it is possible to get the new mopidy up and running.

But the main point of my post was the congratulations!! This really is a tremendous effort, and a great milestone in the life of mopidy.



To my knowledge OpenSUSE also does not support python 3.7 by default. Also ubuntu and derivatives makes a half of all users ? I’m not saying that this is wrong move, I want only to point out that for now it makes mopidy harder to use for some users and this may be bad for the project (for now). And I’m just curious what features of the python 3.7 are so usefull that project maintainers decided to use this version ?

for example In my home I have 9 linux machines and 8 of them use ubuntu or mint :slight_smile:

How about Raspbian Stretch? I know it’s not exactly the most recent distro, but it’s still the standard for many of the RaspberryPis out there. In order to use mopidy on a RaspberryPi pre-Buster one will either have to dist-upgrade or keep the old package.

It is not that you have to upgrade the os. You can install python3.7 on older oses to, but it requires compiling Python by yourself. It just requires additional effort.

Please remember that Ubuntu LTS is a risk-adverse distribution aimed at enterprise users who want stability i.e. not for users wanting to run latest versions. If you don’t want Ubuntu’s rolling releases then stick with Mopidy v2.3.1 along with the other old software until Ubuntu 20.04 LTS comes out in April. Having said that, there will be instructions of sorts for those who want to mess around trying to use 18.04, it just won’t be a supported platform i.e. don’t raise github issues about it.

I’m afraid Stretch (oldstable) is definitely not supported. We support Gstreamer >= v1.14, Stretch has something like v1.10. I’m very glad to see us move forward, away from the bugs and workarounds needed for v1.10. There are great new features in v1.14 and now we get to finally start using them. This is good.

Of course one can compile Python 3.7 on an older OS, but that would guarantee nightmares when it comes to handling Python extra packages installed via apt. Plus, gstreamer would still be a breaking dependency (not that I mourn gstreamer <= 1.10 much, but it’s more because of the faults on gstreamer than those on mopidy).

After a brief look at the changes, it seems that the main reason for a Python >= 3.7 requirement is the support for the new format strings. While I love the compact format strings introduced in Python 3.6, I don’t see any argument in favour of them being the only factor to break the integration on Debian oldstable.

While upgrading to stable on server machines isn’t usually a big deal, it is quite a big deal when it comes to a RaspberryPi with the OS installed on an SD card. Buster was only introduced by the end of June; breaking compatibility so hard within 6 months since the release of Buster just for the sake of having the new cool format strings isn’t probably a very wise decision.

I really don’t follow you here. Python 3.7 is the default Python 3 version in Buster (currently Debian stable). If you are running Buster you are fine. If you are still running Stretch (oldstable), that is your choice and that’s fine too - enjoy using your older software or enjoy jumping through a series of increasingly complicated hoops (on your own).

FYI f-strings came in Python 3.6. When we have a choice, our minimum requirements usually follow Debian stable. That’s chiefly in terms of Python, GStreamer and Tornado. Debian stable != Ubuntu LTS.

I don’t think I can help any more here. Please enjoy Mopidy 3.0, we worked hard on it.

It’s not that hard for me to upgrade to Buster, or to compile Python 3.7 (or even Python 3.8), replace most of the apt-installed python- packages with pip versions and still install mopidy 3 - although it takes time. The issue I raised wasn’t specific about me, it was more about the current state of the RaspberryPi platform - which I guess is one of the principal targets for mopidy. Raspbian Buster has only been released by the end of June (before Debian forked the stable), at the same time as the RPi4 release. It means that most of the RaspberryPis out there are still RPi3 or previous models, and my guess is that, within 6 months, more than 90% of them haven’t been upgraded to Buster yet. It means that mopidy 3 won’t work on most of the RaspberryPis out there. I was just wondering if the breaking requirement of Python >= 3.7 was worth it. As far as I could see from the code the only major breaking change with Python 3.5 compatibility is the new format strings (I might be wrong), so I was just wondering if forcing an upgrade of most of the RaspberryPis out there was really worth, or if maybe the breaking changes with Python 3.5 could have been introduced more gradually.