Argument parsing error: directory positional argument is swallowed by -d flag when using all

[SnazzyNivesh522]

When using the -d (or --debris) flag with the all keyword, the subsequent positional argument (the directory path) is incorrectly parsed as a choice for the -d flag. This results in an invalid choice error.

However, using the assignment syntax (e.g., -d=all) works as expected.

Reproduction Steps

1. Install pyclean (v3.6.0).
2. Run the command:

   pyclean -d all ./

3. Observe the error:

   pyclean: error: argument -d/--debris: invalid choice: './' (choose from all, cache, coverage, ...)
   

Expected Behavior

The CLI should recognize all as the argument for -d and ./ as the positional directory argument.

Actual Behavior

The parser attempts to include ./ as a choice for the -d flag's list of topics.

Environment

• pyclean version: 3.6.0
• Python version: 3.12.12
• OS: AlmaLinux 9.7 (Moss Jungle Cat)
• Installation Method: Poetry

Additional Context

The issue seems to be that -d accepts multiple values (nargs='*'). When all is provided without an equals sign, the parser continues to consume following strings.

• Fails: pyclean -d all ./
• Works: pyclean -d=all ./
• Works: pyclean ./ -d all

[bittner]

Thanks for reporting this issue! 💯

I know about this usability problem and acknowledge that this is both an irritating issue and a tricky one to fix. The behavior in general is the one provided by the Python standard library's ArgumentParser. That said, there are certainly ways to make the problem in question less acute.

What I have thought to do for a long time is to make the positional directory argument entirely optional. This way, most users would never even try to use a dot (or any other directory name) after the -d option. The downside of this choice – and the reason I was and still might be reluctant to remove the mandatory nature of the argument – is that running pyclean without arguments would immediately start to clean up the execution directory. (This is not dangerous per se, but might surprise some users.)

If you have any actionable suggestion about what specifically can and should be changed – taking the behavior and limits of argparse into consideration – your input is more than welcome.