Highlight weight-applying plugins at candidate selection

Is there a way, during import when the cadidates list is shown, to display which plugin added a positive/neutral/negative weight (red/green colors + plugin names?) and also to show which plugin(s) added a particular candidate?
For example, if I have a plugin that i trust more than others then I want to know if this plugin added its weight to certain candidates or if it added new candidates.

If this isn’t currently possible, could anyone point me in the right direction so that I can make this possible?

Not currently, no! In fact, while I’m definitely having a slow day, I can’t at the moment think of any plugins we currently have that can affect the matching weight. There is chroma, which provides MBIDs—that currently shows up as id in the list. Did you have a specific plugin in mind?

Well, there is my own plugin https://github.com/8h2a/beets-barcode.
In the case of a barcode, I know that this is exactly the correct release and I want to know whenever that plugin favours a specific candidate.
Other than that, only the chroma plugin comes to mind atm.
I can see that this might be a bit of a special use-case.
I will just try and figure out if I can add this information to disambig_string.

(Also I have at least one more plugin planned that would also change the weight and would benefit from such a UI change)

Got it! Actually, this should be happening already—it just might not be apparent. I see you’re using the distance key album_id:

Here’s the code for generating that penalty string:

As you can see, it somewhat naively strips off prefixes from all the keys. So when your penalty is triggered, it’s just showing “id”. Maybe it would make sense to just use a different name for the penalty?

Oh, I see.
I suppose that would solve my problem as well.
I initially didn’t know what that string did and used album_id because I thought it would fit well.
Thank you very much!

edit: So the distance_key has no other purpose than to show the reason of the penalty?

On second thought, it might not solve my problem.
This only prints the distance_key if there’s actually a penalty applied.
So I can see those candidates that were penalized, but not those that are preferred (or even added) by that plugin. Even then it only shows the plugin name only if there’s not too many different penalties (because of the limit).
This also means that there’s no indication if there’s only a single candidate.

Appending the plugin name to the data_source would make it show the plugin name, however that might not be the cleanest solution.

Allowing negative penalties could solve this issue though. (Is there a reason why they are not allowed? We could count and show negative penalties similar to the others but with a different color)

So in summary, opposite-penalties would be nice, but simply changing the data_source would solve my issue with the least amount of code changes.
Unless there’s another way that I’m not seeing here.

Edit: I could of course also add another property to the AlbumInfo, but showing that would require changes in the beets core.

I like the idea of adding to the data source field! Another thing we could consider adding to the beets importer UI is a special field just for showing a “note” during import time. This could be separate from the data source and just serve as a hint to the user.

“Negative penalties” are an interesting idea. But I think you can see how that would make some things we do in beets feel “backwards.” Internally, it’s nice to know that there’s a minimum distance—0.0 (i.e., 100% similarity). If penalties can go in both directions, for example, it’s possible to go below distance 0.0.

Thank you for your input and quick responses!

For now I just added it to the data_source field and (using ui.colorize) it even looks nice, so I’ll just keep it like that:

Would plugins add their own “notes” to the candidates (or maybe the imported album instead) (which then gets displayed if the user wishes to display notes from that particular plugin)?
Or did you have something else in mind?

Awesome! Yeah, that’s exactly what I had in mind for a “notes” field.