Re: [Proposal] Representing repeatable Starlark flags as config.string_list

36 views
Skip to first unread message

Fabian Meumertzheim

unread,
Mar 8, 2022, 3:28:19 PMMar 8
to baze...@googlegroups.com, Greg Estren
Forgot to add the link to the proposal, here it is:
https://github.com/bazelbuild/proposals/blob/main/designs/2022-03-06-representation-of-repeatable-starlark-flags.md

Fabian

On Tue, Mar 8, 2022 at 8:35 PM Fabian Meumertzheim <fab...@meumertzhe.im> wrote:
>
> With this proposal, repeatable Starlark command-line flags are
> represented as string_list rather than string settings and can have
> any list-type default (previously, only singleton lists were possible
> as defaults).
>
> It's only a small proposed change, but feedback is still very welcome.
>
> Fabian

Greg Estren

unread,
Apr 12, 2022, 4:42:02 PMApr 12
to Fabian Meumertzheim, bazel-dev, Ara Nguyen
This slipped through the cracks for me, I apologize.

I'm working with @Ara Nguyen on examining updates to the Starlark flags API to make it more generic (particularly powerful enough to model more of Bazel's native flags). 

I think that's a nice tie in to this: particularly clarifying what ultimate support for repeatable flags we want to imagine in the API (and where it's supposed: in BUILD files, in .bzl logic, etc.).

Please stay tuned as we sync these together.

gre...@google.com

unread,
Jun 23, 2022, 7:36:22 PMJun 23
to bazel-dev
Update: we have a sync scheduled for next week.

Interim feedback:
  • Generally looks great: clean API, more robust implementation, simpler code
  • I'm not sure about a string vs. boolean parameter since string type may be so much more general than needed. While boolean makes the behavior less clear I'd think API documentation should carry the weight of those concerns
  • I support combining the new API with removal of the old. And yeah, I think we'd have to have a migration flag.
  • I think with native allow_multiple there has historically been complication with users legitimately wanting different interpretations of `--foo=a,b --foo=c,d`. i.e. some flags wanted that to be ["a, b, c, d"] while others wanted [["a", "b"], ["c", "d"]]. I think your choice to not parse the commas is the right one that elegant handles this. Any flag definition that also wants to parse commas can do it in post-processing.
  • As a sanity check, does a transition implementation's flag setting logic also work intuitively and robustly with the new API?

Reply all
Reply to author
Forward
0 new messages