Decide how to handle newly-split `google_cloud_*` packages
h-vetinari opened this issue · 2 comments
In order to reduce the footprint of the binding for GCP in google-cloud-cpp, and even more importantly, to get the build times back under 6h, there are now three 4 more feedstocks, and many more packages.
- https://github.com/conda-forge/google-cloud-cpp-core-feedstock
- https://github.com/conda-forge/google-cloud-cpp-ai-feedstock
- https://github.com/conda-forge/google-cloud-cpp-bigquery-feedstock
- https://github.com/conda-forge/google-cloud-cpp-compute-feedstock
Additionally, these packages all come with a split into the library (libgoogle-cloud-foo) and the headers/metadata (libgoogle-cloud-foo-devel).
In particular, feedstocks will be able to use the smaller devel packages to compile against smaller pieces of libgoogle-cloud, and therefore have a smaller runtime footprint - e.g. conda-forge/arrow-cpp-feedstock#1305
AFAICT, we'll need to add all the devel packages to the global pinning, because a given recipe may use nothing else than a single libgoogle-cloud-foo-devel in host.
Given the number of these packages, I nevertheless wanted to raise this point for discussion. As of now, the list would look like:
google_cloud_cpp: # legacy setup
- '2.17'
libgoogle_cloud: # legacy setup
- '2.17'
libgoogle_cloud_devel:
- '2.17'
libgoogle_cloud_all_devel:
- '2.17'
libgoogle_cloud_aiplatform_devel:
- '2.17'
libgoogle_cloud_automl_devel:
- '2.17'
libgoogle_cloud_bigquery_devel:
- '2.17'
libgoogle_cloud_bigtable_devel:
- '2.17'
libgoogle_cloud_compute_devel:
- '2.17'
libgoogle_cloud_dialogflow_cx_devel:
- '2.17'
libgoogle_cloud_dialogflow_es_devel:
- '2.17'
libgoogle_cloud_discoveryengine_devel:
- '2.17'
libgoogle_cloud_dlp_devel:
- '2.17'
libgoogle_cloud_iam_devel:
- '2.17'
libgoogle_cloud_oauth2_devel:
- '2.17'
libgoogle_cloud_policytroubleshooter_devel:
- '2.17'
libgoogle_cloud_pubsub_devel:
- '2.17'
libgoogle_cloud_spanner_devel:
- '2.17'
libgoogle_cloud_speech_devel:
- '2.17'
libgoogle_cloud_storage_devel:
- '2.17'
The one big difference with the AWS setup is that these all have the same version and we can migrate them in sync, rather than individually.
CC @conda-forge/core @coryan
Unless we come up with an additional implementation in conda-smithy that would be able handle wild-card keys in the pinning file (it could be that this also needs features in conda-build which would make it even more complicated), we will need to stick with mentioning so many libraries here.