search

conda-forge / google-cloud-cpp-feedstock

A conda-smithy repository for google-cloud-cpp.
BSD 3-Clause "New" or "Revised" License
2 stars 10 forks source link

refactor: use o11y libraries from core feedstock #165

Closed coryan closed 4 months ago

coryan commented 4 months ago
conda-forge-webservices[bot] commented 4 months ago

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.

h-vetinari commented 4 months ago

FYI, if you don't want to run into a stale cache of a not-yet-up-to-date CDN from the time when the build launched, the easiest thing is to wait until the dependencies you need have made it through the CDN, before you launch a build that is otherwise doomed to fail (and then have to wait for the restart, etc.).

As a first approximation for determining availability, you can check the info for any package produced from a given CI run on the anaconda website, say libgoogle-cloud-logging in the case of https://github.com/conda-forge/google-cloud-cpp-core-feedstock/pull/11 (normally easily clickable from the feedstock README if feedstock is correctly rendered). As a rule of thumb:

To be absolutely sure whether a package made it through (in corner cases, or because it simply gets no downloads), use:

mamba repoquery search <package>=<version> -c conda-forge -p <platform>

If it gets found, it's available, if not, then not. The <version> specification should be tight enough to catch the build you're looking for (not necessary here because it was the first publication; otherwise something like =2.21.0=*_1 if you want to catch the build number). <platform> is simply linux-64, win-64, etc.

h-vetinari commented 4 months ago

So we have the following warnings, which are actually something we should get rid of:

ClobberWarning: This transaction has incompatible packages due to a shared path.
  packages: conda-forge/win-64::libgoogle-cloud-logging-devel-2.21.0-h63175ca_1, local/win-64::libgoogle-cloud-all-devel-2.21.0-h63175ca_1
  path: 'library/include/google/logging/type/http_request.grpc.pb.h'

The way to get rid of this normally is to include the respective package as a host dependence for whatever's being built, which means that conda will take these files into account as already present when doing its before-after checkpointing mechanism, and so the files will not be "identified" as belonging to libgoogle-cloud-all-devel.

It's slightly curious that this isn't happening for any of the other feature-libraries though (not sure if there's some bug related to that somewhere).

coryan commented 4 months ago

So we have the following warnings, which are actually something we should get rid of:

ClobberWarning: This transaction has incompatible packages due to a shared path.
  packages: conda-forge/win-64::libgoogle-cloud-logging-devel-2.21.0-h63175ca_1, local/win-64::libgoogle-cloud-all-devel-2.21.0-h63175ca_1
  path: 'library/include/google/logging/type/http_request.grpc.pb.h'

Ack.

The way to get rid of this normally is to include the respective package as a host dependence for whatever's being built, which means that conda will take these files into account as already present when doing its before-after checkpointing mechanism, and so the files will not be "identified" as belonging to libgoogle-cloud-all-devel.

It's slightly curious that this isn't happening for any of the other feature-libraries though (not sure if there's some bug related to that somewhere).

I forgot about these:

https://github.com/googleapis/google-cloud-cpp/blob/81307825abd4154ee5bd3233ee612f07b33f8982/google/cloud/appengine/CMakeLists.txt#L22

The shared protos are built by the first feature that needs them:

https://github.com/googleapis/google-cloud-cpp/blob/81307825abd4154ee5bd3233ee612f07b33f8982/cmake/GoogleCloudCppLibrary.cmake#L208-L210

So disabling the logging feature in this feedstock and building logging in the google-cloud-cpp-core feedstock still gets them compiled and installed to satisfy the needs of other features.

@dbolduc no action needed, as I think we have a good workaround for now, but these make the libraries harder to shard. Maybe we should define real features for such shared protos, so we can compile them as part of the core feedstock. Or maybe we can add an option to disable the "automatically build shared protos" magic. That is the safer setting for packaging (and should be the default?). I will open a feature request.