Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add plugin for formatting albumtypes #4048

Merged
merged 8 commits into from
Sep 10, 2021
Merged

Add plugin for formatting albumtypes #4048

merged 8 commits into from
Sep 10, 2021

Conversation

edgars-supe
Copy link
Contributor

Description

Added a plugin to add a configurable album template field $atypes to format albumtypes of an Album (see #4045).

Should I rename the plugin to atypes since that's the field it adds, and to reduce possible confusion with the actual field albumtypes?

To Do

  • Documentation. (If you've add a new command-line flag, for example, find the appropriate page under docs/ to describe it.)
  • Changelog. (Add an entry to docs/changelog.rst near the top of the document.)
  • Tests. (Encouraged but not strictly required.)

Copy link
Member

@sampsyo sampsyo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow; nice work! This looks awesome so far. I have a few suggestions for the code and some documentation improvements for your consideration.

super(AlbumTypesPlugin, self).__init__()
self.album_template_fields['atypes'] = self._atypes

def _atypes(self, item: Album):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps add a docstring, like "generate a formatted string for an album's types"?

Comment on lines 35 to 39
self.config.add({
'types': [],
'ignore_va': [],
'brackets': '[]'
})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This stuff should go in __init__; otherwise, it will try to set the defaults every time we use the $atypes field.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point!

Would it not be better to extract the config values (next lines after this) in __init__() as well, so it's not done every time _atypesis called? I see both approaches in other plugins, so I suppose it's not a big concern, but converting config to those structs isn't exactly free.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is less of a big deal, IMO, and it's fine to do it either way. The reason is that config.add(...) actually modifies config: it inserts a new "layer" with the default configuration values. So doing this every time actually adds multiple copies of that data. In contrast, get and as_* calls are read-only, so it doesn't matter as much where they appear.

is_va = item.mb_albumartistid == VARIOUS_ARTISTS_ID
for type in types:
if type[0] in albumtypes and type[1]:
if not is_va or (not type[0] in ignore_va and is_va):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not type[0] in ignore_va is probably more clearly written type[0] not in ignore_va.

for type in types:
if type[0] in albumtypes and type[1]:
if not is_va or (not type[0] in ignore_va and is_va):
res += bracket_l + type[1] + bracket_r
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be a little easier to read as a PEP 498 format/template string? Like: f'{bracket_l}{type[1]}{bracket_r}'

Comment on lines 5 to 6
such as "Album", "EP", "Single", etc. List of available type can be found
`here`_.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe for this last link, I'd word it as: "For the list of available album types, see the MusicBrainz documentation." (with the last two words linked)

Comment on lines 9 to 10
(see :ref:`using-plugins`). Then, add ``$atypes`` to your path formats as
desired.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"The plugin defines a new field $atypes, which you can use in your path formats or elsewhere."

- **types**: An ordered list of album type to format mappings. The order of the
mappings determines their order in the output. If a mapping is missing or
blank, it will not be in the output.
Default: ``[]``.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just say "Default: None." ([] implies it's a list, not a mapping.)

But also… should the default be nothing? Does that mean that $atypes will always be empty by default? Perhaps this should come with a default mapping, like the one shown below, so the plugin is useful "out of the box"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good idea, I think. I've set the default values to the example config and adjusted the docs accordingly.

- **ignore_va**: A list of types that should not be output for Various Artists
albums. Useful for not adding redundant information - various artist albums
are often compilations.
Default: ``[]``.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, perhaps the default here should be what's shown below—i.e., "compilation"? It seems like a sensible default for most people.

albumtype:soundtrack Various Artists/$album ($year)$atypes)/...
comp: Various Artists/$album ($year)$atypes/...

Example outputs::
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"This configuration generates paths that look like this, for example::"

Pink Flow/(1995)(Live) p·u·l·s·e
Various Artists/20th Century Lullabies (1999)
Various Artists/Ocean's Eleven (2001)(OST)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably no need for this extra line.

@edgars-supe
Copy link
Contributor Author

I've done the improvements you mentioned, added sane defaults, etc.

The comment about formatting output got me wondering, though: would it not be better to provide prefix, separator and suffix config values? That way with, say, [, , , ] you could have [EP, Remix], if that's what you prefer. Or (, )(, ) to have the current output.

Also, still wondering if I should rename the plugin to atypes, because that's the template field it adds and to not confuse it with the actual field on Album. Thoughts?

Copy link
Member

@sampsyo sampsyo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! This looks great; I think it's basically good to go.

About the additional configuration values: I don't have a strong feeling either way! I definitely can envision people wanting a formatting like [EP, Remix]. But it's also totally fine to merge a minimal version of the plugin that fits your needs and to add more features later, "on demand," as people actually want them. (To philosophize for a moment, that strategy can be higher-overhead but lead to outcomes that more closely match what users want.) May I leave that decision up to you?

I usually have opinions about naming, but I am also finding myself without a strong feeling about the plugin name… I definitely see the argument for naming it the same as the field it creates, but the current name helps describe what it does. So again, I'm perfectly happy either way!

are often compilations.
- **bracket**: Defines the brackets to enclose each album type in the output.

The default configuration looks like this: ::
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The default configuration looks like this: ::
The default configuration looks like this::

(I believe this is equivalent.)

@edgars-supe
Copy link
Contributor Author

Either way is fine with me, so I'll just leave things as they are currently. I don't personally have a need to do [EP, Remix]. :D
I'll perhaps work on that at some point, but if anyone expresses a strong need for such a feature, I can do it, no problem.

I adjusted the docs based on your comment, so if there's nothing more, it's ready to be merged. :)

@sampsyo
Copy link
Member

sampsyo commented Sep 10, 2021

Excellent! Nice work on this!! 🎉 🚀

@sampsyo sampsyo merged commit e1d41c2 into beetbox:master Sep 10, 2021
@edgars-supe edgars-supe deleted the albumtypes-plugin branch September 10, 2021 20:49
arogl added a commit to arogl/beets that referenced this pull request Sep 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants