Discussion: interactive vs non-interactive disc/release selection

[Freso]

While morituri strived to be fully automated and not provide any interactivity what-so-ever. (At most, you could specify things on the command line when invoking morituri.) However, this approach also means that sometimes you're likely to get the wrong metadata, e.g., for multiple releases with the same Disc ID, or even for a single release with multiple discs having the same Disc ID.

I would suggest adding a minimum level of interactivity by default. If a Disc ID resolves to multiple discs (on multiple releases or a single release), it should ask how to proceed (e.g., give an option of the matched mediums and ask user to select one (and maybe possible to open the "Add release from Disc ID" page)). Possibly with a timeout (e.g., if no response in 60 seconds, bail out).

Another option could be to instantly balk when it can't resolve a Disc ID to a release (unless an --interactive flag was used?), letting the user know how to select which release to use in the next invocation (using the --release-id option, possibly with a new --medium option or something, depending on #166).

But ultimately, I guess it depends on how @JoeLametta, @RecursiveForest, @MerlijnWajer et al sees whipper's mission compared to morituri's. Do we want to do more or less exactly the same (in which case the instantly balking is more correct), or can we diverge a little from morituri's mission (in which case we can at least consider adding a slight bit of default occasional interactivity)?

[Hoolean]

I would much appreciate such a feature. Failing this, as a temporary fix, how are people retagging their files with the correct release (including renaming etc, if done)?

[MerlijnWajer]

Sounds like a good feature to have, but we should be careful not to overboard too much - how would you diff the releases? Just show all releases in links, or do you want to diff them? etc

[Freso]

I've thought some more on this, and I currently think we should default to allow some level of interactivity, but also have a flag (--unattended or --non-interactive or some such (what's usually used?)) to make whipper err out if it encounters anything that requires user input/confirmation.

I also think this flag should be in place for whipper 1.0.0 if this is what we go for, to limit breaking scripts etc. that may rely on whipper's behaviour of interactivity (or no). (I know SemWeb prescribes that it's okay to break API between major versions, but that doesn't mean we have to do so more than we have to. :))

[MerlijnWajer]

We could also print a message on warnings like these and tell the user to pass --interactive to resolve the situation. I'm fine with both.

[JoeLametta]

@Freso, @MerlijnWajer I agree with both your proposals.