#17900 Refactor code parsing options to handle options names wrt to the goal scope Issue created by AlexTereshenkov Is your feature request related to a problem? Please describe. When writing a plugin, it's possible to add a custom option, e.g.

run_bar = BoolOption(
        default=False,
        help="Run bar.",
    )

to be later used:

$ ./pants dummy --run-bar myapp:   
Unknown flag --bar on run scope
Did you mean --args?
Use `./pants help run` to get help.
[ERROR] Unknown flags --bar on scope run

This happens because when parsed, Pants thinks that the option

run_bar

is really the

--bar

option from the built-in

run

goal. The workaround is to be verbose and tell Pants this option comes from a custom goal scope:

$ ./pants dummy --dummy-run-bar myapp:
...
[INFO] Completed.

Likewise, adding a custom goal with unfortunate name may break existing options, e.g. having a goal named `local`:

$ ./pants --no-local-cache local                           
Unknown flag --no-cache on local scope
Did you mean --no-check-git?
Use `./pants help local` to get help.
19:33:54.25 [ERROR] Unknown flags --no-cache on scope local

Describe the solution you'd like It would be helpful to be able to add options and goals with arbitrary names without worrying that they may clash with any existing options during the scope resolution. Describe alternatives you've considered I've documented this limitation for now, see #17899 pantsbuild/pants

#17900 Refactor code parsing options to handle options names wrt to the goal scope Issue closed as completed by AlexTereshenkov pantsbuild/pants