refactored to create packages for all extra requirements (grpc, grpcio-gcp, grpcgcp)

[BrentDorsey]

Checklist

• [x ] Used a fork of the feedstock to propose changes
• [ ] Bumped the build number (if the version is unchanged)
• [ ] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x ] Ensured the license file is being packaged.

• updated to latest version
• refactored to create packages for all extra requirements (grpc, grpcio-gcp, grpcgcp)
• implemented exhaustive import test
• expanded description
• implemented pin_compatible
• resolved all over linking and over depending

Thanks,

BrentDorsey hill-country-machine-learning

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[tswast]

Thanks. Looking good once the Python 3.6 builds pass.

[BrentDorsey]

I'm not sure how to fix the python 3.6 builds because it's not the recipe configuration that's making it fail it's something in the conda-forge azure build pipeline configuration.

The current recipe configuration builds successfully locally for python 2.7, 3.6 and 3.7.

Do you have any thoughts on why the conda-forge azure build pipeline is installing python 3.7 requirements in the python 3.6 package plans? Pull Request #20 isn't experiencing this issue.

Pull Request #21 (this PR):

• linux_python3.6 - Failed Azure build log Package Plan all packages are py37 and noarch packages?
• osx_python3.6 - Failed Azure build log Package Plan again all packages are py37 and noarch packages?

It's no surprise the 3.6 builds are failing, all the packages are py37!

Pull Request #20:

• linux_python3.6 - Successful Azure build log Package Plan - all packages are py36 and noarch
• osx_python3.6 - Successful Azure build log Package Plan - all packages are py36 and noarch

Thoughts?

[BrentDorsey]

success! key takeaways

Set the python host requirement in the root package for multiple output (packages) recipes that don't qualify as noarch because the recipe has a dependency which requires a specific version of Python. For example google-api-core has a futures requirement for Python < 3.2 so this package does not qualify as noarch and needs to set the python host requirement in the root package.

With the root python host requirement set a compatible version of Python can be pinned in the core package and removed from the subpackage run requirements to resolve subpackage overdepending.

Also, due to the way the platform/python VARIANT_CONFIG_FILES in .ci_support are used there's no way to disable a platform build for a given version of Python for a single package in a multiple output recipe (recipe that creates more than one package). With multiple outputs, it's all or none when it comes to using preprocessing selectors to skip building the recipe for a platform.

For example, even though it's technically possible to build a Python 2.7 google-api-core package for windows it can't be built with this recipe because we don't have a Python 2.7 grcpio package for windows available in conda-forge so the other 3 outputs in this recipe,google-api-core-grpc, google-api-core-grpcio-gcp, google-api-core-grpcgcp, which require grcpio can't be built for windows with Python 2.7. Python 2.7 is deprecated anyway so not a big deal, just good to know.

DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date.

[BrentDorsey]

@tswast - This PR is ready to merge whenever you are.

[tswast]

Thanks for the huge contribution @BrentDorsey and volunteering to be a maintainer!

[BrentDorsey]

Thanks Tim, happy to help!