You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So the cautious-robot usage auto-overwrites the output file using from sumbuddy import get_checksums. The interruption happens in sum-buddy's CLI, the interruption happens as a check before get_checksums is called. So using Python, this does not interrupt a script. If someone used the CLI command in a script though, that would get in the way. A few redesign options:
CLI keeps prompt, add a -y / --yes in the command to skip.
Smallest change. Existing interactive UX preserved; scripted CLI users pass -y. Library untouched. Closes Add flags for non-interactive use #11 with the narrowest possible scope. CLI/library inconsistency remains.
CLI refuse by default + -f / --force to overwrite.
Replace the prompt with a clear error message and a flag. Always non-interactive: either it works, or it exits with "use --force." Library untouched, no breaking change. CLI/library inconsistency remains but the CLI itself is cleaner.
Full unification, refuse-to-overwrite-by-default everywhere.
CLI and library both refuse by default. Library adds force=False parameter; CLI gets -f / --force. Breaking library API change. Requires 2.0.0 + cautious-robot one-line patch (force=True). I think this is maybe the cleanest end state.
I think 3 makes the most sense in the context of this package. For one, the "force" behavior models git, as we've endeavored to do throughout development (e.g., .sbignore). Secondly, it makes sense to keep behavior consistent between CLI and Python to try to avoid unexpected outcomes should a user switch between the two.
Activity
thompsonmj commentedon Apr 27, 2026
So the cautious-robot usage auto-overwrites the output file using
from sumbuddy import get_checksums. The interruption happens insum-buddy's CLI, the interruption happens as a check beforeget_checksumsis called. So using Python, this does not interrupt a script. If someone used the CLI command in a script though, that would get in the way. A few redesign options:CLI keeps prompt, add a
-y/--yesin the command to skip.Smallest change. Existing interactive UX preserved; scripted CLI users pass
-y. Library untouched. Closes Add flags for non-interactive use #11 with the narrowest possible scope. CLI/library inconsistency remains.CLI refuse by default +
-f/--forceto overwrite.Replace the prompt with a clear error message and a flag. Always non-interactive: either it works, or it exits with "use
--force." Library untouched, no breaking change. CLI/library inconsistency remains but the CLI itself is cleaner.Full unification, refuse-to-overwrite-by-default everywhere.
CLI and library both refuse by default. Library adds
force=Falseparameter; CLI gets-f/--force. Breaking library API change. Requires 2.0.0 + cautious-robot one-line patch (force=True). I think this is maybe the cleanest end state.egrace479 commentedon Apr 28, 2026
I think 3 makes the most sense in the context of this package. For one, the "force" behavior models
git, as we've endeavored to do throughout development (e.g.,.sbignore). Secondly, it makes sense to keep behavior consistent between CLI and Python to try to avoid unexpected outcomes should a user switch between the two.Add force flags for non-interactive overwrite
Add control over overwrites for non-interactive use (#47)
thompsonmj commentedon Jul 29, 2026
Closed by #47