Add Support for Development Cocoapods

[sanju-naik]

At present the plugin doesn't support Development Pods, it raises an Error.

This MR adds support for Development Pods by creating a symlink to the Local Pod directory and placing it inside the Pods/ directory this way it behaves the same as other Pods.

The approach is based on the suggestions offered in the error message raised earlier.

[mattrobmattrob]

I don't feel incredibly strongly but I think it'd be nice for this functionality to not be part of this plugin.

For example, I've used this in the past to store "development" pods (these were really just custom podspecs stored in the workspace/repo) in the workspace/repo and referenced in the Podfile in the standard way and it worked fine.

Can you do that instead? Either via git submodules or your own symlinks.

[sanju-naik]

I am trying to achieve what the Cocoapods + Xcode build system does by default because the audience here are, folks who don't know much about Bazel.

For example, I've used this in the past to store "development" pods (these were really just custom podspecs stored in the workspace/repo) in the workspace/repo and referenced in the Podfile in the standard way and it worked fine.

To do this I think we need to manually create a symlink to local pod spec, etc? instead wouldn't it be nice if the plugin handles this and things work out of the box? OR do you see any potential downsides to having this in the plugin?

As I explained above our developers are not used to Bazel yet, so we are trying to match default Xcode + Cocoapods behavior otherwise we need to document this flow which might create some unnecessary confusions.

[mattrobmattrob]

My critique is mostly that this plugin has a very narrow focus right now. Something like "Write BUILD files for CocoaPods" and you're expanding it to creating/deleting symlinks that are an implementation detail of your dev pod workflow that could be fixed by having people store the dev pods in the workspace and using .gitignore (or however you store files) to ignore the folder that contains them. Then this plugin would work without changes.

[thiagohmcruz]

+1 to not expand the scope of what this plugin solves, IMO we should keep it simple so folks can include in their workflow as one piece of infra that can be composed with other custom/internal ones. If we start adding functionality "just because we can" we might end up with undesired/unnecessary maintenance burden long term.

[sanju-naik]

Ok understood, cool makes sense, thanks for the explanations 👍