Refactor discogs_tagger.py
triplem opened this issue · comments
This module has slightly outgrown itself. I believe we should do a refactoring, to make future enhancements easier.
There are a couple of opportunities here:
Make the whole config handling easier -> handle this in its own module and use the parameters from an object, this will also make the setting of default values easier, in that those are not set in the taggerutils.py but in the one configure handling module.
Refactor the track-loop, so that this can be adopted easier then right now. Probably we should define an own object "Track"/"TrackContainer" and define certain properties on this one.
Refactor the source directory determination to allow for batch calls (e.g. my source dir is ~/Music and in there are several sub-directories which contain audio files). Up until now the source dir has to contain (except multi-disc releases) audio files.
the wrapper (discogs_tagger) has become quite messy . Will target some changes to help with cleanup.
Hello,
have already started with this one. No real changes to the wrapper, but I added unit tests and a Data Model for the data coming from discogs. Also I added some. changes to the tagger utilities. Please see the version2 branch in my fork.
The unit tests for the model are in place now, the unit tests for the taggerutils are in progress and it looks quite nice. I would like to refactor the taggerutils and the discogs_tagger, so that most of the above still holds true. The above branch (version2) is not really working right now, but the target should be quite clear.
Use an intermediate data structure (album.discs.tracks) is already in place, there are a lot of refactorings for the config handling, which are mostly done as well. In the next steps I am working on adding most of the methods from the discogs_tagger to the taggerutils (rename it probably to taghandler) and then the discogs_tagger script is just there to determine what dirs to tag and to put the whole directory (directories) into the taghandler, so that this object can take care about this.
Like stated, there is still some work ahead but this seems to be doable ;-)
version2 looks pretty good, there are still some adjustements needed, any help is welcome ;-)
closing this old ticket, as work to separate and refactor the configuration data was completed in v3.0.0