Value mismatch for the option level

[bdabelow]

Describe the bug
Running pants with -l=debug (or apparently any value other than info) causes:

08:22:29.52 [WARN] Found differences between the new native options parser and the legacy options parser in scope [GLOBAL]:

- Value mismatch for the option `level`:
    Legacy value: LogLevel.INFO of type <enum 'LogLevel'>, from source HARDCODED
    Native value: LogLevel.DEBUG of type <enum 'LogLevel'>, from source FLAG

I have used pants -l=debug help global to reproduce, but also happens with other commands. The error does not occur when using the long form --level=<value>

Pants version
Can reproduce with 2.22.0 and 2.23.0a0.

OS
Linux

[benjyw]

Thanks for the report, I'll take a look asap.

[benjyw]

Interestingly, this happens only when using an = sign: -l=debug. -ldebug doesn't give a discrepancy.

In fact I'm mildly surprised that -l=debug even works. Short flags were not intended to take an equals sign.

[benjyw]

This seems like a bug in the discrepancy calculator, since the discrepancy is:

- Value mismatch for the option `level`:
    Legacy value: LogLevel.INFO of type <enum 'LogLevel'>, from source HARDCODED
    Native value: LogLevel.DEBUG of type <enum 'LogLevel'>, from source FLAG

But we are seeing the debug output, so the legacy value used in practice is not actually INFO but DEBUG. I will take a closer look.

[bdabelow]

As a side remark, pants help is showing the short option with equals sign:

[benjyw]

Ha, OK, I see what's going on. So, -l=debug is not supported in the legacy parser (I'm not sure why it doesn't error), but is supported in the native parser. It so happens that log levels are consumed and applied by pantsd, which is written in Rust, so we still see debug logging (if we add --no-pantsd then we no longer get debug logging with -l=debug).

[benjyw]

As a side remark, pants help is showing the short option with equals sign

Well that's just adding insult to injury... :(

[benjyw]

I am reluctant to change the behavior of the legacy parser at this late stage, since it's about to be deleted in 2.24.x, and I fear ripple effects and inadvertent breakage.

Is using -ldebug an acceptable workaround? It would just be for 2.22.x and 2.23.x, since, as mentioned, this will all work on the native parser alone in 2.24.x.

[bdabelow]

Is using -ldebug an acceptable workaround? It would just be for 2.22.x and 2.23.x, since, as mentioned, this will all work on the native parser alone in 2.24.x.

Sure, this works for me.

Is the help output also generated by the parser and will be fixed once the switch to the native parser is completed? Or should I create a separate issue for that?

Or should help remain as is, as short options with equals sign will be supported with the native parser IIUC.

[benjyw]

I think an issue for that would be good, thanks. It is true that it will work with an equals sign, but it's not how short options are intended to be used, so it's probably preferable for the help output to say the right thing...

[benjyw]

Will close this one, thanks!