Core features vs. plugins?

[ali-ramadhan]

Hi @jtpavlock thank you for open sourcing Moe, it looks great! I've been playing around with it for a bit and quite like how clean it is. Also my first experience with poetry which I'm eager to start using!

I love beets but it is lacking some features that probably won't get implemented and it feels that changes are hard to merge now. I was considering forking it and just making my own small changes when I came across Moe.

I was wondering if you had a sense of what will become core features (living in this repository) and what will become plugins living in other repositories?

I know you've mentioned in #192 that source plugins (Discogs, Spotify, etc.) should be external plugins. What about plugins that do similar jobs as beet's inline and rewrite? I know you also talked about first-class support for attachments which I'm very interested in.

[jtpavlock]

Thank you for the kind words! This is a good question, and to be honest, something I haven't entirely fleshed out yet.

It may be easier to talk about plugins I don't want in the core repository. For now that list looks something like:

1. Plugins specific to an external platform (discogs, plex, mpd, genius, etc.)
2. Plugins implementing something niche that most users won't benefit from or use.

Generally, I'm more open to things that extend the functionality of already existing plugins or create other interfaces to ease/increase extensibility.

Because reason 2 can be a bit vague or subjective, I'd still like to take plugins/features on a case-by-case basis. You mentioned the inline and rewrite plugins of beets. I'm not a big fan of writing code in configuration files; I'd much rather like to promote local plugins. For instance, the example of the rewrite plugin can just be a local plugin .py file that contains:

import moe

@moe.hookimpl
def create_path_template_func():
    return [canon_artist]

def canon_artist(artist):
    if artist == "The Jimi Hendrix Experience":
        return "Jimi Hendrix"
    return artist

Then in your path template you'd write canon_artist(track.artist)

While a bit more verbose, I think this approach allows greater flexibility and easier debugging when your config python goes wrong. The examples in the inline plugin can either be implemented fairly easily as well either immediately in the f-string template, or again, as another path function.

So for those plugins specifically, I'd say no to implementing them directly in the core repository.

[ali-ramadhan]

Completely agree with your reasoning, and I am also not a big fan of how the inline plugin required embedding code into your configuration file.

Thanks for the rewrite example, didn't realize that writing Moe plugins is this easy! Will definitely play around with writing some simple plugins to bring my moe config closer to my beets config.

Another reason I asked about plugins is that I'm trying to figure out how many Moe plugins I would need to make Moe match beets for my tagging needs. Even though I feel like my beets config is kinda beefy (https://github.com/ali-ramadhan/music-tagging/blob/main/beets_config.yaml) I don't think I would need much to migrate over, especially since Moe has support for multi-valued tags and attachments.

The ones I'm thinking of are albumtypes, bucket, rewrite, and the, which all seem like they should be rather easy to implement as external Moe plugins.

[jtpavlock]

Thanks for the rewrite example, didn't realize that writing Moe plugins is this easy!

No problem, I do think I could probably do a better job of showcasing that in the 'writing plugins' docs.

The ones I'm thinking of are albumtypes, bucket, rewrite, and the, which all seem like they should be rather easy to implement as external Moe plugins.

Definitely let me know if you run into any issues, or if the docs could be improved at all as you dig through them! I'd be happy to help where I can.