Allow the gRPC module name to be customised when generating code

[glbrntt]

Motivation:

Some Cocoapods may find themselves in a situation where their dependency
graph contains both gRPC Swift and the gRPC core library. This is
problematic since both have the same module name ("GRPC"). Changing our
own module name is a very large breaking change and one we'd like to avoid.
As an escape valve, users who take a direct dependency on us may rename
our module via their Podfile; doing so would require their generated
code to depend on that module, rather than the currently hardcoded
'GRPC' module.

Modifications:

• Add an option to the codegen to specify the gRPC module name
• Remove a couple of imports which were previously used but are now no
  longer required
• Regenerate

Result:

It's possible for Cocoapods users to take a direct dependency on gRPC
Swift and libgrpc.

[MrMage]

Could you please also document this in https://github.com/grpc/grpc-swift/blob/main/docs/plugin.md?

[MrMage]

This "fixes #915." If you encounter conflicting module names, please follow this process:

1. Download our current Podspec from https://github.com/grpc/grpc-swift/raw/main/gRPC-Swift.podspec and place it next to your Podfile.
2. In the downloaded gRPC-Swift.podspec, replace s.module_name = 'GRPC' with s.module_name = 'GRPC_Swift'.
3. Include the dependency in your Podfile as follows: pod 'gRPC-Swift', :podspec => 'gRPC-Swift.podspec'
4. Change your protobuf codegen script to include --grpc-swift_out=GRPCModuleName=GRPC_Swift in your options (or append it to the end of an existing config string).

Whenever we tag a new release, I'm afraid you will need to repeat steps 1 and 2 (or manually increment s.version in gRPC-Swift.podspec).

[MrMage]

Looks good. I wonder whether we should also include the steps from my comment, WDYT?

[glbrntt]

Looks good. I wonder whether we should also include the steps from my comment, WDYT?

If anything I'd think they should be included in the README, I suspect If someone hits this they might search the README but will be unlikely to look in the plugin docs.

[MrMage]

If anything I'd think they should be included in the README, I suspect If someone hits this they might search the README but will be unlikely to look in the plugin docs.

Fine with me as well. Maybe just mention in the README to look here when encountering this particular issue?

[vlopezferrando]

This "fixes #915." If you encounter conflicting module names, please follow this process:

1. Download our current Podspec from https://github.com/grpc/grpc-swift/raw/main/gRPC-Swift.podspec and place it next to your `Podfile`.

2. In the downloaded `gRPC-Swift.podspec`, replace `s.module_name = 'GRPC'` with `s.module_name = 'GRPC_Swift'`.

3. Include the dependency in your Podfile as follows: `pod 'gRPC-Swift', :podspec => 'gRPC-Swift.podspec'`

4. Change your protobuf codegen script to include `--grpc-swift_out=GRPCModuleName=GRPC_Swift` in your options (or append it to the end of an existing config string).

Whenever we tag a new release, I'm afraid you will need to repeat steps 1 and 2 (or manually increment s.version in gRPC-Swift.podspec).

Please note that the option for protobuf codegen is --grpc-swift_opt=... and not --grpc-swift_out.

[nshoura]

Hello everyone,

How can the mentioned solution work when gRPC-Swift is used as a dependency for another pod since, in podspec files, it's only allowed to define the name and the version specifier of a Pod?
Basically, the following isn't valid:
s.dependency 'gRPC-Swift', :podspec => 'gRPC-Swift.podspec'

[Artfire]

@nshoura
Hi,
Did you solve this issue? I faced with the same issue and could't not find any solutions.
Thanks