> Might be good to post this in the user list and get feedback first. Sure, done. Given early support, I will probably move forward with the change tomorrow if I don't hear otherwise (it is easy to rollback if needed before the next release).
On Wed, May 14, 2025 at 12:43 PM Chamikara Jayalath via dev < dev@beam.apache.org> wrote: > +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 >>>> >>>
