Add aliases support

[sezaru]

Description

This PR add support for aliases to releases, release-groups and recordings.

This PR is a must have (IMO at least) for people that listen to Japanese, Chinese and other songs that has other symbols for letters. With this, not only the artist name will use the alias if available, but now the album and track name will also use aliases.

NOTE: This PR requires a fork of the python-musicbrainzngs package. That package seems to be dead (more than 2 years without any commit) and is lacking in a lot of updates to Musicbrainz API.

Here is my PR adding support for the new fields alastair/python-musicbrainzngs#289 but I have no hope that will be merged since the package seems to be dead.

Personally I think beets can create a fork of that package and just add the bare minimum to it to make new features work (for example this one).

I didn't add any tests and changelog changes yet since this PR requires forking python-musicbrainzngs, so first I want to discuss if this can be merged and then after getting the confirmation I will add the missing parts.

[Serene-Arc]

I would really like this functionality. However, there is #4936, which completely replaces the musicbrainzngs package and instead embeds that functionality in beets itself. That seems like the best option, given that the other project is more or less dead.

I would ask you to consider looking at that PR and how you can use it, since I will begin reviewing it now.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Morikko]

I would really like this functionality. However, there is #4936, which completely replaces the musicbrainzngs package

The replacement is stale for quite a while now. And because of the size of the change and impact, it requires a lot of developers and beets maintainers availability. Pragmatically, It can not be expected to happen soon.

Personally I think beets can create a fork of that package and just add the bare minimum to it to make new features work (for example this one).

I tend to agree with that statement, this and maybe other propositions may continue to improve beets in the meantime without being blocked by uncertain deep refactoring.

As long as new propositions are tested, it should mitigate the risk of regression that the new musicbrain binding change could be subjected to.

Could it be reconsidered ?

[snejus]

This branch needs to be rebased on master since there's been a fair bit of updates since the PR was opened.

Additionally, it would be great if you could adjust one of the tests to show that this new title resolution works as intended.

[snejus]

This is duplicated in 4 places. Could you define a function to deduplicate it?

[Morikko]

I don't know if @sezaru plans to resume his work else I can continue it. But before, there is this requirement that needs to be sorted:

Here is my PR adding support for the new fields alastair/python-musicbrainzngs#289 but I have no hope that will be merged since the package seems to be dead.

Personally I think beets can create a fork of that package and just add the bare minimum to it to make new features work

Would the beets maintainers agree to fork it to accept MR to extend beets features ?

[snejus]

@Morikko, this may be slightly complicated. We won't be able to publish a new version of the package and will have to depend on the GitHub URL of the fork, which is not ideal.

MusicBrainz have a simple JSON API, I wonder whether we could remove this dependency and talk to MB directly. Let me see how much effort would this require.

[snejus]

Here we go: #6052