It appears that the traditional python bindings are not maintained anymore GitHub - alastair/python-musicbrainzngs: Python bindings for Musicbrainz' NGS webservice
Could we consider to put the python bindings in a dedicated library so it can also be used by other projects ? I guess that would also give the ability for other projects to contribute on those.
I think it’s mainly /picard/webservices and oauth2.
Picard’s Webservice classes are based on Qt and hence are only usable for PyQt5 based projects. Furthermore they consist of a general class to do HTTP requests, which is in need of some refactoring, plus a helper that implements MB specific calls as needed by Picard. It does not provide general support for all web service calls supported by MB.
What exactly is it you are missing in musicbrainzngs or what is not working there? It’s for sure easier to add that there than reworking the Picard code into a standalone library.
musicbrainzngs has 40 issues, 13 PR, no action for 2.5 years and nobody to take the lead. In my concern, there is no support for oauth2. People from beets say the dependency to xml is too important and that the lib should be rebooted.
In my opinion, the architecture from Picard looks smart even though it uses QT libs. The best way to reboot a python binding might be to start thinking from there.
I can understand that is not a priority for picard dev team.
There is no “Picard dev team” in any official sense. There are some lead volunteers who are those with most experience and who are the gatekeepers for Pull Requests being merged into the code base, but Picard is Open Source and anyone can get involved and create Pull Requests.
The Python-MusicBrainzNGS (hereafter PMngs) repo is owned by Alastair Porter who is a member of the Metabrainz team and lead for AcousticBrainz, but who is not a significant contributor or lead on either MusicBrainz or Picard. So Alastair is around and actively involved in Metabrainz even if PMngs is not being actively maintained.
An educated guess suggests that:
- If someone wanted to take a lead role in the ongoing (backwardly-compatible) development of PMngs, Alastair (or the Metabrainz leadership) might be favourably disposed to sharing control of the repo. But the only way to find out is to ask.
- If not (and the current repo is therefore effectively morbid) then there is (of course - this is open source) nothing to stop you forking the project and creating your own updated version. The only restrictions would seem to be to respect the existing copyright statements and not make it closed source.
As an aside, as an experienced open source contributor to several projects, I would add the following thoughts:
MusicBrainz is a tremendous and mature resource, and the more people making use of this data the better. IMO it helps a lot to have a set of pre-written access routines to assist users in accessing and making sense of the data. PMngs is one example of this, and having it more actively maintained would IMO be a good thing.
I have never used PMngs myself, but a quick look at the repo suggests the following:
There have been a few tweaks over the years but this is essentially 11 year old code and could probably do with quite a lot of updating or even serve as inspiration for a more modern take on this which does more interpretation of the MB responses and perhaps delivers MB data in a more object-oriented result set (i.e. with objects corresponding to MB objects (artists, release groups, releases, recordings, works, etc.).
It was almost certainly written to work with Python 2 (which has been fully obsolete for some years now) and this may well lead to constraints which can now be avoided i.e. the code probably needs modernising in other ways.
If Picard is anything to go by, whilst accessing specific MB release records is powerful, flexible search-for / navigation-between these records is even more powerful, and Picard functionality in these areas could well be used as another source of inspiration for a new more rounded package.
It was not exactly the subject but you’re right.
It was mostly a message in a bottle. I understand the answer is no, the picard webservice can’t be externalized to serve generic bindings.
Thanks for your time and answers !
@Louson Actually, that is the polar opposite of what I am saying.
What I am saying is that the MusicBrainz webservice is a public API and thus already externalised. Picard uses this webservice through its own code. PMngs is another piece of Python code that utilises this webservice.
I am also saying that you can get involved in improving PMngs, or you can create your own competing Python library to use this API or indeed create a library in C++, C#, PHP, JS, Rust, or any other language to utilise this API.
Tagging @rob becuase we use some MB Webservice APIs in Troi and it also has some model classes for the same. It might be useful to redo the library in question here then use it in Troi but ofcourse its not a small task.
It’s really not a good starting point. Using the webservice code from Picard would mean every application wanting to use the library would need to depend on PyQt and needs to run a Qt event loop.
And if you remove the Qt part there is not much left except for some very light wrappers, and half of that is very specific to Picard.
Either the existing musicbrainzngs or completely writing a new library from scratch would be the better solution for new Python bindings for MB webservice.
I also agree that a modern Python binding should get rid of the XML part and rely on the JSON output and provide some helpers for oauth authentication.
Personally I mostly avoid wrapper libraries over JSON based REST services like the MB webservice. IMHO using a good HTTP library like urllib3 or requests to handle the requests is often more flexible. If there should be a new generic MB webservice library I’d suggest making it a thin wrapper over such an existing HTTP library.