App: implement managing multiple projects (#107) #109
Conversation
See the issue for more details
Following feedback on #107, this patch implements saving the ultratrace metadata directly in the directory containing the source files. In addition, it changes the way we construct Projects and FileBundleLists so that we avoid half-constructed objects.
|
Next up: tests! |
Co-Authored-By: Caleb <[email protected]>
…nlab/ultratrace into manage-multiple-projects
Co-Authored-By: Caleb <[email protected]>
Co-Authored-By: Caleb <[email protected]>
Co-Authored-By: Caleb <[email protected]>
Co-Authored-By: Caleb <[email protected]>
…nlab/ultratrace into manage-multiple-projects
Co-Authored-By: Caleb <[email protected]>
Co-Authored-By: Caleb <[email protected]>
Co-Authored-By: Caleb <[email protected]>
NB: These tests only test for INVALID input. There are currently no
tests for VALID input (since that behavior is not defined yet).
Still unresolved: - How can we specify the desired resolution order (and still allow it be flexible / extensible)?
Python already includes a standard library for working with mimetypes, so it's unclear why we were ever using `python-magic`.
| def set_alignment_file(self, alignment_file: AlignmentFile) -> None: | ||
| def set_alignment_file(self, alignment_file: AlignmentFileLoader) -> None: | ||
| if self.alignment_file is not None: | ||
| logger.warning("Overwriting existing alignment file") |
There was a problem hiding this comment.
@calebho This is another reason why we might want some kind of resolution order. Consider the case where we're scanning a directory that contains XYZ.wav and XYZ.mp3 (assuming we know how to handle both). Clearly, we would prefer the losslessly encoded wav file, but under the current system he one we "end up with" depends only on the order of directory traversal.
There was a problem hiding this comment.
Clearly, we would prefer the losslessly encoded wav file
Are you sure that this matches the user's preference? If all users always have this preference, why would they include the recording in both encodings?
I'm not sure how this relates to having more than one loader for a given extension. Perhaps I'm misunderstanding what you mean by "resolution order".
There was a problem hiding this comment.
A user might have a lossy file around for easy playback / demonstration purposes.
For a real example of something similar, I usually use flac for things like this (lossless compression), but might have wavs around because that's what the original data was recorded in and I don't like keeping the original around. (The choice between wav and flac would just be one of resources: speed (wav better?) or memory (flac better?).)
There was a problem hiding this comment.
I'm not sure how this relates to having more than one loader for a given extension. Perhaps I'm misunderstanding what you mean by "resolution order".
So by "resolution order", I mean two separate things:
-
As Jonathan mentioned,
$userhas filesXYZ.flacandXYZ.wav:- As we traverse the directory, we encounter both.
- WLOG, let's say we encounter
XYZ.flacfirst. - We retrieve
FLACFileLoaderfrom the registry and successfully loadXYZ.flac. - We save it to
bundles["xyz"].sound_file. - We continue traversing, and we encounter
XYZ.wav. - We retrieve
WAVFileLoaderfrom the registry and succesfully loadXYZ.flac. - We go to save it to
bundles["xyz"].sound_file, but that's already been set. - Currently, we just print a
logger.warningand overwrite it, but we might want to give certain loaders "preference" over others, so that we might always chooseFLAC, for example.
-
$userhas the fileABC.flacand registersMyFLACLoaderwith mime types["audio/x-flac", "audio/flac"]and extensions["flac"].- We traverse the directory and encounter
ABC.flac. - We try to retrieve from the registry, but error out since it found two possible loaders, but, again, we might want to give certain loaders "preference" over others (presumably user-defined ones should be preferred, but then what happens if they try to register
MyOtherFLACLoaderwith the same mime types / extensions?).
- We traverse the directory and encounter
I think (1) is a real possibility, and (2) is also possible but less likely. One solution I can see is to present the user with a dialog for choosing their "FileBundle associations" (i.e., which sound file corresponds to which alignment file corresponds to which image-set file) in the case of conflicts, but to resolve automatically where possible.
There was a problem hiding this comment.
Currently, we just print a logger.warning and overwrite it, but we might want to give certain loaders "preference" over others, so that we might always choose FLAC, for example.
Ditto. For now I think it makes sense to hard code this preference, then expose it as a user configurable thing later.
We try to retrieve from the registry, but error out since it found two possible loaders
Does it make sense to differentiate an audio/x-flac FLAC from an audio/flac FLAC? Aren't they the same?
we might want to give certain loaders "preference" over others (presumably user-defined ones should be preferred, but then what happens if they try to register MyOtherFLACLoader with the same mime types / extensions?)
Does it make sense to have multiple loaders registered at once? We can have the notion of preference without keeping all possible preferences loaded at the same time.
There was a problem hiding this comment.
Currently, we just print a logger.warning and overwrite it, but we might want to give certain loaders "preference" over others, so that we might always choose FLAC, for example.
Ditto. For now I think it makes sense to hard code this preference, then expose it as a user configurable thing later.
OK, at what level in the abstraction would be enforce that? Give each FileLoader a priority class attribute and take the highest?
We try to retrieve from the registry, but error out since it found two possible loaders
Does it make sense to differentiate an
audio/x-flacFLAC from anaudio/flacFLAC? Aren't they the same?
Yes, they are equivalent. But that's not the reason it found two ... each file only has one mime type. So WLOG, ("audio/x-flac", "flac") could map to FLACLoader (built-in) and MyFLACLoader (user extension).
we might want to give certain loaders "preference" over others (presumably user-defined ones should be preferred, but then what happens if they try to register MyOtherFLACLoader with the same mime types / extensions?)
Does it make sense to have multiple loaders registered at once? We can have the notion of preference without keeping all possible preferences loaded at the same time.
I think probably it does not make sense. We could emit a logger.warning if we're overwriting an existing FileLoader at register-time.
There was a problem hiding this comment.
Does it make sense to differentiate an
audio/x-flacFLAC from anaudio/flacFLAC? Aren't they the same?
Ftr, the reason we have both in there is because we were getting files identified as either. I forget if it was platform-specific or file-specific, but we definitely needed it to respond to either.
See #109 (comment) for more context.
Co-Authored-By: Caleb Ho <[email protected]>
Apparently, `global` is only necessary for assignment, and these functions only need to access the value.
Instead, let the exceptions propagate up to the caller. For one thing, this allows us to write more specific tests :^)
keggsmurph21
force-pushed
the
manage-multiple-projects
branch
from
4f86115 to
e6895ba
Compare
keggsmurph21
force-pushed
the
manage-multiple-projects
branch
from
ceb0642 to
2669b54
Compare
See issue #107 for more details