beets
beets copied to clipboard
beetbox
plugins: add importhistory
Description
Add a plugin useful for bulk importers.
To Do
- [x] Documentation. (If you've add a new command-line flag, for example, find the appropriate page under
docs/to describe it.) - [x] Changelog. (Add an entry to
docs/changelog.rstnear the top of the document.) - [ ] Tests. (Encouraged but not strictly required.)
I have planned to finally look into this PR but I just can't get to it. In the meantime I'd like to mention that I have a quite similar plugin I'm maintaining (original maintainer doesn't use beets anymore). It certainly has a slightly different approach but just wanted to mention and maybe on the long run this could be merged into one plugin (....or not! It might be too different). Also it is pretty old code which I just quickfixed somehow to make it work for my needs. Just want you to have a look if you're interested: https://github.com/JOJ0/beets-dirfields
Hey @JOJ0 , after a mostly successful review process, I'd like to bump this PR upwards :) I hopefully fixed the formatting issues, and maybe CI will be green now. I also took a look upon the dirfields plugin and I think that this PR is much more mature - it includes docs as well as another feature described in the docs here, that isn't included in the competing plugin.
I finally found the time to read through the docs. Very useful and well written. Loads of useful usecases! Great!
Keeping track of the source path alone is the killerfeature for me❤️
I have one highlevel question regarding that: Will the sourcepath stay untouched in case for some reason I do a reimport from the items already in the library: beet import -L ...
Will the sourcepath stay untouched in case for some reason I do a reimport from the items already in the library:
beet import -L ...
Good question, I had no idea this option existed. Is there a way to know what events this action triggers?
Thanks for all the comments. I'm glad you liked the idea in general, and that we only have to fine-tune the details of the implementation. I think that having tests would be nice, and it'll take me time to delve into it. I'll keep you notified! In the meantime, I pushed a commit fixing the easy issues presented by @sampsyo .
Will the sourcepath stay untouched in case for some reason I do a reimport from the items already in the library:
beet import -L ...Good question, I had no idea this option existed. Is there a way to know what events this action triggers?
Best you just test a reimport using that option and see what value source_path has after that. I have a feeling that it might the beets library path and the original source_path gets lost. Give it a try and we'll see if it does. HTH :-)
Hey all,
I was busy for a while, and I had some time left today to fix some of the issues discussed back than, including a small bug I encountered while experimenting with the plugin personally. The commits I just pushed fix these issues, and I also marked the review conversations above as resolved, but of course feedback is still welcomed.
I didn't have time though, to think thoroughly about @JOJ0's question:
I have one highlevel question regarding that: Will the sourcepath stay untouched in case for some reason I do a reimport from the items already in the library:
beet import -L ...
So don't feel like you need to review this now once more - this is still not ready enough.
Hmm now I checked and saw that (before the last push) using beet import --library on items that were imported, indeed changes the source_path field to the path from the music library. I managed to fix that by using an additional listener to the import_task_choice event.
Now I also fixed the small merge conflict, so this is ready for another round of review :). I think it'd be nice to write tests, but perhaps it'd be good to get your :+1: at this stage.