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.

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: failed

Thus the PR was not passing and not merged.

I think the 002-* patch is no longer needed. Let me try to fix that.

I think the 002-* patch is no longer needed. Let me try to fix that.

Quick-fix is just to comment out that line in the patches: section. Proper fix is rebasing the patches¹ and regenerating with

git format-patch tags/v2.12.0 --no-signature

I'm happy to do the latter, but even happier if you want to try your hand at this!

Hi! This is the friendly conda-forge automerge bot!

It appears that not all commits to this PR were made by the bot. Thus this PR is not being automatically merged. Please add the automerge label again (or ask a maintainer to do so) if you'd like to enable automerge again!

I think the 002-* patch is no longer needed. Let me try to fix that.

Quick-fix is just to comment out that line in the patches: section. Proper fix is rebasing the patches

Thanks. I would have missed rebasing the 0001-* patch, and the line numbers do change.

Thanks. I would have missed rebasing the 0001-* patch, and the line numbers do change.

The changed line-numbers aren't critical as the patch will still apply with some fuzz, but git generally resolves a lot more things (through its knowledge of the history) than what a dumb application of patch ... will be able to figure out, so it's still good practice to rebase & regenerate.

We're getting into problematic spheres here unfortunately. Windows on protobuf 3.21 (with the disablement patch) already took 5:48h, which is pushing against the 6h hard cutoff enforced by azure. Without that feature disablement, we go from building 6917 build steps to 7027, which is not such a big change, but seemingly enough to push it over the edge (also not all agents are equally spec'd, so there's some randomness involved).

Still, the OSX builds for protobuf 4 are not far behind (way over 5h), so we're probably going to have to start thinking about how to slice up this package somehow. Is there a way to define a core library upon which we can build, or tranches that can be built independently?

Is there a way to define a core library upon which we can build, or tranches that can be built independently?

We should probably move this discussion to a bug? In any case, yes we can do this. The current behavior is to build all the GA libraries:

The list is defined here:

https://github.com/googleapis/google-cloud-cpp/blob/dcc823e8dd34b61fe26aab5bf69f7438ca1801a8/cmake/GoogleCloudCppFeatures.cmake#L36

And it grows over time (maybe one or two features a month, though some "features" can be quite large). There are a set of (implicit) common features that we could build first or separately. Then the features are largely independent from each other, with a small number of caveats:

https://github.com/googleapis/google-cloud-cpp/blob/dcc823e8dd34b61fe26aab5bf69f7438ca1801a8/cmake/GoogleCloudCppFeatures.cmake#L166-L183

I am not sure how to translate this into the conda packaging model. Should we create different packages for the core components and then a package for each feature? That seems a bit overwhelming. Any other thoughts?

While we figure out a more permanent fix, we could disable some of the new features. That would reduce the build time without breaking any existing applications. Thoughts?

aiplatform is particularly large.

While we figure out a more permanent fix, we could disable some of the new features. That would reduce the build time without breaking any existing applications. Thoughts?

aiplatform is particularly large.

I'm happy to disable features to get us building again. Obvious candidates would be those that got re-enabled in this PR, or those that got added between 2.11 & 2.12. Does the latter apply to aiplatform?

While we figure out a more permanent fix, we could disable some of the new features. That would reduce the build time without breaking any existing applications. Thoughts?
aiplatform is particularly large.

I'm happy to disable features to get us building again. Obvious candidates would be those that got re-enabled in this PR, or those that got added between 2.11 & 2.12. Does the latter apply to aiplatform?

Yes. The new features between 2.11 and 2.12 are:

I used the lines of code as a proxy for "size", it is imperfect, for the well-known reasons (comments, blank lines, documentation, etc.) but good enough for our purposes. As you can see, it is larger than all the other features combined.

I would not be sad if we disabled all the new features until we come up with a better plan. Thoughts?

Hi! This is the friendly conda-forge automerge bot!

Commits were made to this PR after the automerge label was added. For security reasons, I have disabled automerge by removing the automerge label. Please add the automerge label again (or ask a maintainer to do so) if you'd like to enable automerge again!

I would not be sad if we disabled all the new features until we come up with a better plan. Thoughts?

For now I'm trying to just disable aiplatform on windows as a sort of "minimal" fix, but I'm not opposed to going as far as disabling all new 2.12 features on all platforms.

So, windows passed now pretty effortlessly -- looks like aiplatform is really big (like ~1.5h in our windows CI big¹).

I'm fine with leaving things like that, but would also be happy to disable it on unix as well.

I'm fine with leaving things like that, but would also be happy to disable it on unix as well.

It seems like we need to do that too?