+1. I've never used this either :) Might be good to post this in the user list and get feedback first.
On Tue, May 13, 2025 at 4:54 PM XQ Hu via dev <dev@beam.apache.org> wrote: > https://github.com/apache/beam/issues/34101 is planned for Beam 2.66.0 > > On Tue, May 13, 2025 at 7:42 PM Kenneth Knowles <k...@apache.org> wrote: > >> +1 I did not even realize this existed, for Beam or elsewhere. >> >> The usual shell UX is for shortened synonyms to accept a single dash and >> be unambiguously specified, not a flexible match against the longer name. >> This "feature" really is a minefield. >> >> The breaking change should have minimal impact, since best practice in >> scripts aka prod is always full parameter names. The abbreviated parameter >> names are for saving typing during interactive usage. >> >> Let's not innovate in the command line interface arena, and stick to data >> processing :-) >> >> Kenn >> >> On Tue, May 13, 2025 at 5:07 PM Danny McCormick via dev < >> dev@beam.apache.org> wrote: >> >>> Today, you can abbreviate arguments in Beam Python. This is generally >>> convenient since you can do things like specify `--r` instead of >>> `--runner`, and Beam will infer your intent. >>> >>> Unfortunately, it also has unintended side effects. For example, >>> specifying `--u` will impact not just `--update`, but also >>> `--update_compatibility_version` (caused bug fixed by #34083 >>> <https://github.com/apache/beam/pull/34083>), and specifying `--output` >>> like we do in most of our examples >>> <https://github.com/search?q=repo%3Aapache%2Fbeam+%22--output%22+language%3APython&type=code&l=Python> >>> will impact `--output_executable_path` as well (notably, this cannot be >>> fixed in an easy way like `--update_compatibility_version` since both >>> `--output` and `--output_executable_path` might be expecting strings). >>> There is not an easy way to resolve this, and it only gets worse as we add >>> more flags over time. The `--output_executable_path` argument is >>> particularly relevant as we move more python pipelines to prism which >>> depends on that arg. We could probably find a band-aid, but it's going to >>> be ugly and a temporary patch at best. >>> >>> To resolve this, I'm proposing making a one time breaking change to get >>> rid of argument abbreviation. This will cause existing pipelines which are >>> using this feature to no longer pick up abbreviated flags. In most cases, >>> this will lead to obvious changes in behavior or failures (e.g. a runner is >>> not specified correctly and now tries to run with the local runner), but in >>> some cases the issue may be more subtle. I do not think there is a great >>> way around this. >>> >>> I'd like to get thoughts - does anyone have objections or other ideas on >>> how we can handle this gracefully? I have >>> https://github.com/apache/beam/pull/34934 as a WIP PR to do this. >>> >>> Thanks, >>> Danny >>> >>
