Skylark support for custom build flags

[gregestren]

Part of the Skylark build configuration project.

This is a tracking issue for the ability of Skylark writers to define custom command line flags to configure build properties.

For example:

$ bazel build //my:binary --some_feature_specific_to_my_app=fancy_mode

This complements the Bazel Configurability Roadmap. Write questions / comments / status updates here. See there for the bigger picture.

[juliexxia]

Planning on implementing a new skylark module 'config' to help rules define themselves as build setting rules. Waiting on #5637 to make that change so we don't break users who have global vars named 'config'.

[gregestren]

2018 EOY update:

This feature is partially done.

The flags have been created, but they haven't been fully piped through all pieces of Bazel's code yet. This will increase in priority over the first half of 2019.

[gregestren]

April '19 update:

Major strides: this works! Lots of small pieces still being worked on, like complex types or select() support on user-defined flags. This work is being actively prioritized by @juliexxia over this quarter - more precise details available on request.

[yzhao1012]

Sorry to spam:

• Is there a e2e example showcasing this feature?
  I am having a hard time grasp how the whole thing works.

Thanks in advance!

PS: I am guessing this can be used to allow bazel to apply specified command line flags directed by the build rule itself. Is that the case?

[ghost]

April '19 update:

Major strides: this works! Lots of small pieces still being worked on, like complex types or select() support on user-defined flags. This work is being actively prioritized by @juliexxia over this quarter - more precise details available on request.

@gregestren @juliexxia Any chance that user-defined flags will be available/visible to repository rules during the loading phase?

[juliexxia]

@yzhao1012 no apologies needed - documentation is coming very soon but unfortuantely I can't think of an e2e example that exists right now (partially because all functionality is still experimental). Stay tuned!

@beasleyr-vmw How would you envision using flags for repository rules? Since user-defined flags are a part of configuration they almost certainly won't carry any meaningful value during the loading phase when repository rule implementations fxns are executed. But what's your use case?

[ghost]

@beasleyr-vmw How would you envision using flags for repository rules? Since user-defined flags are a part of configuration they almost certainly won't carry any meaningful value during the loading phase when repository rule implementations fxns are executed. But what's your use case?

Vision: Just as environment variables are exposed to repository rules, I'm imagining user arguments visible to repository rules, even if as rudimentary unparsed/unvalidated key-value pairs.

$ bazel build ... --//:product=my_product

def _impl(repository_ctx):
    product = repository_ctx.options.get("//:product")

Use case: I use repository rules to teach Bazel how to integrate with a proprietary artifact manager. To configure/influence the repo rule, my users have to specify their options using environment variables. I'd like to use command-line flags instead.

Motivation: Other parts of our build with product-specific logic rely on --define= options. This means our users have to specify their intended product twice: env PRODUCT=my_product bazel build ... --define=product=my_product. While the new user config options covered by this GitHub issue allow us to move away from --define, we still have the duplicate definition problem. A developer who only works on one product can cheat by updating their .bashrc and .bazelrc, but anyone switching between products can run into trouble if they manually override one without the other.

Thanks for the consideration. Please LMK if I can clarify anything, should move over to bazel-discuss, etc.

[moroten]

When trying it all out, --//:myflag=foo works, but --@rules_my_language//:myflag=foo does not. I've tried to make an alias and then go for the first alternative, but that fails as well with ERROR: Unrecognized option: //:myflag.

Is it a design choice to not allow command line flags from external dependencies? Is a bug so I should file a bug report? Is it a feature request to allow it in v2, possibly via the WORKSPACE file?

[gregestren]

Re: documentation and examples:

• Some good documentation at Starlark Build Configurations
• Standard re-usable definitions of common flag types in Skylib's common_settings module
• A simple end-to-end example at hlopko/bazel_platforms_examples

[gregestren]

@moroten Good question. I'd imagine this is just a TODO. Can you file a distinct bug for that?

Since the core feature is available, I'm going to close this issue in preference for specific bugs / feature enhancement requestss.