-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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 parentwork plugin #3279
add parentwork plugin #3279
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are a few code quality comments!
It's very fun, I'm correcting my students' informatics exams (basic python course) and I'm getting informatics teached at the same time. Thanks for the comments! I never got healthy programming practices teached (at least not on this level). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's one docs comment. To continue the discussion on work_father
: the real reason why I think this should change is that the name is confusingly gendered. Why is this work male, while the other thing is genderless? I would love to use a name that does not have a gender, as "mother" and "father" do. Would direct_parent
or something work as the name for the thing that is not parent
?
This comment has been minimized.
This comment has been minimized.
I don't understand. How can my PR change the test coverage of fetchart? |
Arg, @codecov-io's output is pretty erratic and sometimes misleading. And we have configured it not to post these pull request messages, but sometimes it just does it anyway, for some reason… |
I have one more question: Works on MB change from time to time, and if the work changes, I would like the parentwork to be updated as well. A change in work happens only at a Upon verifying, there is |
One more thing, are there comments on the logging? It feels rather verbose right now, are you fine with that? |
Interesting! Here's one thing I'm uncertain about: which of these two scenarios are you most concerned about adapting to?
The thing is that "1" above seems less likely to be an issue (how often do users really change the MBID for tracks they already have in their library?), but it's easier to deal with—there are a few ways we can consider to track when the MBID has gone out of sync with the work. "2" seems like much more of a real issue, but there's essentially nothing to be done about it—to know whether anything changed, you have to check with the MB server again, which essentially means doing About logging: it's probably OK to be somewhat verbose in "debug" mode. But of course, brevity is the soul of wit. I'll take a look at the log messages now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some logging comments.
Regarding the issue of updating the parent work when things change, this is an instance of the more general issue with metadata fetching covered in #266. We're planning to change how plugins work behind the scenes, and hopefully as part of that process we can solve that issue in a more satisfying way. That's a bigger issue that will take some time to get right though. For example we could model |
Another thought occurred to me about how to simplify the logging: you don't need to do this: self._log.info('processing {} - {}', item.artist, item.title) Instead, you can just do this: self._log.info('processing {}', item) and the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just had some small proofreading comments to add
Thanks for the detailed comments! I think I adressed them all. |
I'm trying to read through https://beets.readthedocs.io/en/v1.4.9/dev/plugins.html#listen-for-events but I don't fully get it: I tried something like
This should call
I'm puzzled, because I wrote |
Hi! I found my error. I changed it to:
This however does not work entirely fine. A try with mbsync gives:
Do you know what the error is? Could it be that it is listening to itself? From the error message, the error seems to come from the logging, but I don't know what is wrong there. Another problem is that it now listens to itself, which means each time it changes a work, it will notice that the corresponding track has been changed and fetch it again. |
Hi! Can we please leave this "automation" feature to a separate pull request? It would be awesome to close the book on the basic version before we start adding fancier features. I was even going to suggest a simpler approach to this that might be a little less surprising to users. It seems little surprising that simple metadata changes with I don't exactly see the source of that error, but it might be caused by the presence of other plugins… |
Ok, so I added a tag |
Seems reasonable to me! But can we leave this enhancement to a separate pull request? (You could even base the new branch on this branch and create the PR now.) |
Ok then this should be it! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I think this really might be the last round of comments!
Co-Authored-By: Adrian Sampson <adrian@radbox.org>
Co-Authored-By: Adrian Sampson <adrian@radbox.org>
Co-Authored-By: Adrian Sampson <adrian@radbox.org>
Merged! Thank you for your long-term persistence in seeing this through! |
New try, closes #2580 .