search

MarketSquare / robotframework-robocop

Tool for static code analysis of Robot Framework language
Apache License 2.0
181 stars 39 forks source link

`--option=value` arguments are ignored (equal sign instead of space between long option and value) #1100

Open paulzzy opened 1 month ago

paulzzy commented 1 month ago

What happened?

I noticed that Robocop wasn't following the config I specified when I used --argumentfile. See below for a minimal reproducible example.

What command/code did you try to run?

With equal sign:

❯ robocop --argumentfile=/path/to/config . -vv
No config file found or configuration is empty. Using default configuration
...

Without equal sign:

❯ robocop --argumentfile /path/to/config . -vv
Loaded configuration from /path/to/config
...

What is the full error message?

See above: No config file found or configuration is empty. Using default configuration

What did you expect to happen instead?

--option=value and --option value should behave the same. I didn't test options beside --argumentfile but I would assume the same bug is present for any long option. Note that robotidy (and other tools using Python's default argparse config) accepts both --option=value and --option value.

Operating System

No response

Robocop version

5.0.4

bhirsz commented 1 month ago

The problem is that Robotidy and Robocop use totally different cli parser (Robocop uses python default library while Robotidy uses click). This difference already lead to some problems in the past or missing features that had to be implemented separetely. I could add support for key=value options to Robocop but it could be additional work for something that could be supported out of the box of we made switch to click. I need to think about it how I want to approach it - maybe it is good time to switch Robocop cli parser engine to something more modern like click.

paulzzy commented 1 month ago

I think another reasonable approach is to just not support the --option=value format (it seems to be a GNU convention and not everyone follows it). But in that case I think (1) it should be documented and (2) a warning/error should be raised when an unexpected argument is encountered.

bhirsz commented 1 month ago

I will also consider it - switching to click or alternative is a lot of work and its bit of separate subject. As for 2) I agree, it shouldnt silently accept unrecognized arguments. Most likely it was parsed as a file path but I need to check