Standard -p command-line flag no long accepts format parameter

[spencermathews]

Problem

When using the -a, -p, and -F options to the duplicates plugin simultaneously (and combined) the output varies depending on the ordering.

Running this command (and various other permutations):

$ beet duplicates -apF

Led to this problem:

NO OUTPUT

Combining the arguments in various other orderings work fine, for example:

$ beet duplicates -Fap
$ beet duplicates -a -p -F

Note that the output was also as expected when listing the options individually. This seems to be a bug in argument parsing.

Setup

• OS: macOS 10.15.7
• Python version: 3.8.5
• beets version: 1.5.0
• Turning off plugins made problem go away (yes/no): N/A

My configuration (output of beet config) is:

directory: ~/Music/Beets

import:
    copy: no
    write: no

plugins: badfiles duplicates info missing
missing:
    count: no
    total: no
    album: no
duplicates:
    album: no
    checksum: ''
    copy: ''
    count: no
    delete: no
    format: ''
    full: no
    keys: []
    merge: no
    move: ''
    path: no
    tiebreak: {}
    strict: no
    tag: ''

[sampsyo]

Weird! It does seem like a bug. I don't have any great ideas about where to start looking at this… but perhaps just dumping out the parsed command-line options in various circumstances would reveal what's going on.

[jackwilsdon]

Doing some digging, it seems like there's a bug in how we parse the -p flag. I'm not sure if something changed in optparse, but it looks like the -p=path_format version of our flag no longer works, and instead always sets the path format to an empty string, with anything following the -p just being interpreted as positional arguments:

$ beet duplicates -pStrangers
/Users/jack/Music/RAC/Strangers, Pt. I/02 Ello Ello.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/07 Tear You Down.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/01 Let Go.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/03 Hollywood.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/05 Hard to Hold.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/06 Tourist.mp3

It looks like specifying a custom path format is also broken for list:

$ beet list -pStrangers
/Users/jack/Music/RAC/Strangers, Pt. I/01 Let Go.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/02 Ello Ello.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/03 Hollywood.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/04 Cells.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/05 Hard to Hold.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/06 Tourist.mp3
/Users/jack/Music/RAC/Strangers, Pt. I/07 Tear You Down.mp3

So what's actually happening with -apF (and also -paF), is that -p is being set as a boolean flag, but then everything after it is being treated as a query.

[sampsyo]

Huh! Thanks for investigating, @jackwilsdon, and that would absolutely do it. I'll change the title of this issue and, like you say, we'll need to do some digging to see if something changed in optparse (or maybe something changed on our end).

[spavitra1]

Hello, I would like to work on this bug.