Add experimental features concept and implement experimental_deps_debug_and_release

[thiagohmcruz]

• Introduces the concept of experimental features that intentionally break the contract with the .podspec specification in favour of generating BUILD files that enable usage of bazel features that not necessarily exist in cocoapods.
• Add tests for experimental features only so the tests for the default Podfile config remain untouched, trade off here is that tests were duplicated so all cases can be validated against a run with experimental features enabled.
• Adds one first experimental feature called experimental_deps_debug_and_release with this description:

  # When enabled cocoapods-bazel will add one additional config_setting for the 'deps' attribute only
  # containing both 'debug' and 'release' dependencies.
  #
  # In other works when this flag is active cocoapods-bazel will continue to create these:
  #
  # - //Pods/cocoapods-bazel:debug
  # - //Pods/cocoapods-bazel:release
  #
  # and generate the same 'select()' statements for all attributes but 'deps'.
  #
  # Additionaly these new config_setting values will be created:
  #
  # - //Pods/cocoapods-bazel:deps_debug
  # - //Pods/cocoapods-bazel:deps_release
  # - //Pods/cocoapods-bazel:deps_debug_and_release
  #
  # and used only in the 'deps' attribute.
  #
  # This effectively decouple 'deps' from the other attributes from a configuration perspective and allow one to build
  # with different combinations of these settings. One example of a use case is generating release builds with 'debug' dependencies
  # available so debug-only features can be used to inspect/validate behaviour in a release build (some call these "dogfood" builds).
  #
  # From a conceptual perspective this will generate BUILD files with "all" states and allow one to use bazel features to 'select()' the desired ones.
  # This intentionally breaks the contract with the .podspec specification since cocoapods does not have the concept of 'select()'-ing configurations.
  #
  # Still in the context of the use case above ('dogfood' builds), without this experimental feature one would have to
  # change the configurations in the .podspec file from:
  #   `s.dependency 'Foo', configurations: %w[Debug]`
  # to:
  #   `s.dependency 'Foo', configurations: %w[Debug Release]`
  # and re-run cocoapods-bazel to generate the desired type of build and then re-run it again to go back to the previous state.
  #
  # This might be ok for some teams but it prevents others that are interested in using cocoapods-bazel to migrate to Bazel and eventually stop
  # depending on cocoapods. If the generated BUILD files don't contain "all" states and a 'pod install' is always required it's not trivial how to eventually treat the
  # BUILD files as source of truth.

[thiagohmcruz]

Added 1 suggestion inline - I was also curious about if this was some internal thing or part of the cocoapods spec?

This is to support dogfood builds in internal apps but I'm trying to find a generic solution here, suggestions appreciated!

[jerrymarino]

So the predicate configuration is in cocoapods? I noticed it in the docs here: https://guides.cocoapods.org/syntax/podspec.html#dependency

I'm not super familiar with how that logic is working: e.g. doesn't that add the dependencies to both of them? I'd suggest to follow that behavior as the source of truth / requirements.

[thiagohmcruz]

So the predicate configuration is in cocoapods? I noticed it in the docs here:

https://guides.cocoapods.org/syntax/podspec.html#dependency

I'm not super familiar with how that logic is working: e.g. doesn't that add the dependencies to both of them? I'd suggest to follow that behavior as the source of truth / requirements.

I think I have a way to solve it without introducing a breaking change

Thx for the feedback here, will push the changes soon!

[thiagohmcruz]

@congt @jerrymarino this changed significantly and it's now a opt-in feature, PTAL.

[congt]

Could you document the usage of deps_config_setting_overrides somewhere?

[thiagohmcruz]

FYI working on some changes discussed offline with @congt. Essentially we'll go back to the original implementation here but as an opt-in feature instead of changing behaviour.

We agreed that giving the users the ability to override the configs with any arbitrary config can cause confusion and depending on the usage client side can become fragile (the bazel config can be anything, and that can cause conflicts in the select() statements depending on the consumer's setup).

So I'll make the API here more strict, the underlying behaviour will be the same. A consumer will be able to set a boolean saying feature_custom_deps_config_name = true/false (or something like that) and then cocoapods-bazel will generate

• //Pods/cocoapods-bazel:deps_debug
• //Pods/cocoapods-bazel:deps_release Instead of
• //Pods/cocoapods-bazel:debug
• //Pods/cocoapods-bazel:release

Only for the deps attr. This way we decouple other attrs and deps and the API is still limited to a strict set of values defined by cocoapods-bazel.

One other opt-in feature will be something like feature_deps_generate_debug_and_release = true/false so on top of the above a consumer can also ask cocoapods-bazel to generate debug_and_release deps (to address the use case mentioned in the PR description)

These feature can be combined or used independently