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

persist set_fields to media files #3927

Merged
merged 5 commits into from
May 14, 2021

Conversation

bertbesser
Copy link
Contributor

Description

Addresses #3925.

set_fields or --set write all fields through to the imported tracks, instead of setting them on the album only. This might be the most expected behavior, judging by this and this discussion.

Also, this PR wraps setting fields on album and tracks in lib transactions.

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.)

beets/importer.py Outdated Show resolved Hide resolved
beets/importer.py Outdated Show resolved Hide resolved
Comment on lines 581 to 587
for field, view in config['import']['set_fields'].items():
value = view.get()
log.debug(u'Set field {1}={2} for {0}',
displayable_path(self.paths),
field,
value)
self.album[field] = value
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The exact same loop as before, wrapped in a transaction plus amended with changing all items of the album.

Comment on lines 960 to 967
for field, view in config['import']['set_fields'].items():
value = view.get()
log.debug(u'Set field {1}={2} for {0}',
displayable_path(self.paths),
field,
value)
self.item[field] = value
self.item.store()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The exact same loop as before, wrapped in a transaction.

Copy link
Member

Choose a reason for hiding this comment

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

It think there's no need for the transaction here, the only interaction with the database here is in item.store() which already uses a transaction internally.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thx. fixed.

@sampsyo
Copy link
Member

sampsyo commented May 7, 2021

Nice! This seems pretty great to me. What do you think about checking in with folks on the Discourse or Discussions just to do a sanity check about whether this would break anything for anyone? Was anyone relying on using --set to not assign values to individual tracks when in album mode? I can't imagine that there was, but maybe just posting about it and looking for feedback (moving on in the absence of comments in ~2-3 days) would be a useful sanity check.

@bertbesser
Copy link
Contributor Author

Was anyone relying on using --set to not assign values to individual tracks when in album mode?

Yep, this was my fear, too. I also regard this very unlikely. Also, people seem to expect that --set will set each track's tags, like here or here or here.

But I'm also pro-sanity-check, so here we go: discourse and github.

@bertbesser
Copy link
Contributor Author

Hi,

from the feedback we've got I think our approach is right (one used additional config to circumvent the current behavior, the other thinks it's a bug). So imo we can integrate the change.

Cheers.

Comment on lines +590 to +592
for item in items:
item.store()
self.album.store()
Copy link
Member

Choose a reason for hiding this comment

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

It should be sufficient for the transaction to extend only over these three lines, setting the fields above shouldn't interact with the database.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thx, fixed

Comment on lines 777 to 780
for item in album.items():
self.assertEqual(item.genre, genre)
self.assertEqual(item.collection, collection)
self.assertEqual(item.comments, comments)
Copy link
Member

@wisp3rwind wisp3rwind May 13, 2021

Choose a reason for hiding this comment

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

Have you checked that this test fails without the above changes to set_fields? I suspect that due to #2988, this part of the test was already successful before; it doesn't verify that the item tags are actually set and would end up being written to Mediafile tags, though.

Maybe change to

Suggested change
for item in album.items():
self.assertEqual(item.genre, genre)
self.assertEqual(item.collection, collection)
self.assertEqual(item.comments, comments)
for item in album.items():
self.assertEqual(item.get("genre", with_album=False), genre)
self.assertEqual(item.get("collection", with_album=False), collection)
self.assertEqual(item.get("comments", with_album=False), comments)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I checked. It failed without the change. In particular, it would not set the comments. Nevertheless I have adopted your suggestion for a stricter get.

Copy link
Member

@wisp3rwind wisp3rwind left a comment

Choose a reason for hiding this comment

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

I've had a look at these changes: They generally look sound to me (just the implementation, I didn't follow the discussion on whether this is the right approach). I left a few comments: None of them need to block merging, but I think it'd be worthwhile to at least verify correctness of the test.

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.

This is looking great overall. I also think the discussion is trending toward convergence, with no one objecting to the new behavior. So whenever @bertbesser has enough confidence to move forward, I say we can hit that big green button.

@wisp3rwind
Copy link
Member

With you most recent changes (thanks for those!), a few style issues appear to have crept in @bertbesser, see the notes in the changes view: https://github.com/beetbox/beets/pull/3927/files

Would you mind addressing these, too?

@bertbesser
Copy link
Contributor Author

bertbesser commented May 14, 2021

@wisp3rwind Sure. It was me, after all, who forgot to run the linter :-) Fixed (by hand).

Btw: What is the tox-way to reformat the code automatically?

@bertbesser
Copy link
Contributor Author

bertbesser commented May 14, 2021

@sampsyo

... I say we can hit that big green button.

Let's do it :-)

@wisp3rwind
Copy link
Member

@wisp3rwind Sure. It was me, after all, to run the linter :-) Fixed (by hand).

Thanks!

Btw: What is the tox-way to reformat the code automatically?

There isn't as far as I know. You can run the linter with tox -e py39-lint, but there's no automatic formatter. There is some talk of moving to black, but that hasn't materialized yet: #3694

@bertbesser
Copy link
Contributor Author

@wisp3rwind Sure. It was me, after all, to run the linter :-) Fixed (by hand).

Thanks!

Btw: What is the tox-way to reformat the code automatically?

There isn't as far as I know. You can run the linter with tox -e py39-lint, but there's no automatic formatter. There is some talk of moving to black, but that hasn't materialized yet: #3694

Yes, I used tox -e py39-lint and was searching for tox -e py39-lint-fix or similar. Thx for the pointer to the discussion on black.

Cheers.

@wisp3rwind wisp3rwind merged commit eef26d1 into beetbox:master May 14, 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.

3 participants