New API wrapper

[padok]

Hi I just stumbled across this wrapper of the Play Music API.
At first glance it looks well written and documented. Maybe it wouldn't be wrong to implement the addon against it.

https://github.com/thebigmunch/google-music-proto

[thebigmunch]

Just to add that if you did want to switch but would like to use something at the same abstraction level as gmusicapi, see my https://github.com/thebigmunch/google-music library that is built on google-music-proto, which is sans-I/O. It's also quite easy to do your own bare calls if you want something a bit different than what's implemented.

Simpler, cleaner code and API. Brings a number of improvements and features over what's available in gmusicapi, including proper rating and play count incrementing of both library/store songs which might be useful.

[thebigmunch]

PS google-music uses OAuth for the MobileClient as well as MusicManager, and I intend to add configurability to how/where it's stored at some point.

[foreverguest]

Is it Python 3 only?

[thebigmunch]

Is it Python 3 only?

Yes. I forgot that only Python 2/3 addons will be accepted to the official repository for Kodi 18. Python 3-only are for Kodi 19. Kinda sucks; that's a long way out.

[padok]

A workaround might be to use the Python3 test builds for now.
https://kodi.tv/article/attention-addon-developers-migration-python-3
Or would Python 2.7 support also be an option for google-music?

I think this is quite a poor decision by the Kodi team to support Python 3 only starting with Kodi 19.
That would probably be close to the Python 2 End of Life (2020).

[thebigmunch]

@padok Kodi 18 will support Python 3 addons. It's about being listed in the official repository, though I'm not even sure this is listed in the official repository now. Only Python 2/3 addons will be allowed in the official respitory for Kodi 18. If this addon isn't in the official repository, then it's up to the devs to decide on their migration strategy.

As for Kodi. To be fair, at least they finally have a plan. 2-3 years ago I spoke to a couple different Kodi devs, including 1 that was involved on the Python side of things. I was quite vocal in being appalled that they didn't even have a plan for migration. They really hadn't even begun to discuss making a plan in earnest. By this time, the general Python OSS community had been giving the advice for at least a year that new packages should probably just be written for Python 3 instead of worrying about Python 2 compatibility unless there was some specific reason that compatibility was needed.

I'm not sure I see a technical reason why Python 3-only shouldn't be allowed in the repository for Kodi 18, but I haven't looked at the code for it. If Python 3 is supported, addons built with it should just work. I'm not even sure there's a non-technical reason to make addon devs make their code objectively worse by having to support both language versions for year or more. Kodi 18 is supposed support addons of both versions. The Kodi devs should encourage porting directly to Python 3 instead while still allowing Python 2 addons for Kodi 18.

[padok]

@thebigmunch Then I might have got it wrong. I had understood that it is not planned for Kodi 18 to be compatible with Python 3 addons.
I thought the new requirement for official addons is only to prepare for a hard switch at Kodi 19 from python 2 to python 3.

[thebigmunch]

@padok To be honest, it's not as clear as it should be. I made the assumption that them mentioning Kodi 18 test builds with the Python 3 interpreter together with addons needing to be 2/3-compatible for Kodi 18 to mean that it would end up being released with it. But I think you're probably right.

Just makes me glad I never bothered to write any addons for XBMC/Kodi.