Switch to libabseil

[h-vetinari]

Follow-up to #138, with some light clean-ups along the way

[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.

[github-actions]

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

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!

[ngam]

@h-vetinari I am not sure if this is needed. Why don't we just pin harder/exactly in abseil-cpp like we discussed in the following issue? conda-forge/abseil-cpp-feedstock#41

[h-vetinari]

Yes it's needed. Going forward, all feedstocks should replace abseil-cpp -> libabseil, and eventually, we can remove the compatibility wrapper.

[ngam]

Yes it's needed.

Why is it needed?

Going forward, all feedstocks should replace abseil-cpp -> libabseil, and eventually, we can remove the compatibility wrapper.

This is going to be too much of an intervention with a long time already using abseil-cpp and migrations, etc. --- I am not sure if it is worth making this change unilaterally and disrupting maintainers' rhythm.

Maybe I am wrong, but I don't particularly see any benefits, only downsides, from this abseil-cpp -> libabseil change.

[h-vetinari]

The main discussion is in conda-forge/conda-forge.github.io#1073. I've taken the infrastructural changes around the C++ ABI as a good enough reason to finally follow through on this for some of the few outstanding "-cpp" feedstocks. The abseil rename was also discussed in two core dev meetings (I explicitly called it out) and there was no opposition.

This is going to be too much of an intervention with a long time already using abseil-cpp and migrations, etc. --- I am not sure if it is worth making this change unilaterally and disrupting maintainers' rhythm.

There are not that many feedstocks using abseil, and we're not in a rush - the abseil-cpp package keeps working (well, aside from some small papercuts you identified that can be fixed). I'm also happy to contribute this change to the respective feedstocks myself.

So it's really not such a big deal IMO.

[ngam]

I'm also happy to contribute this change to the respective feedstocks myself.

So it's really not such a big deal IMO.

Yes if you are willing to smooth the corners/transition, then yes it is definitely not a big deal. I got the (wrong) impression that the onus will be on maintainers alone, but if you're willing to help and guide through this, then all is good.

Thank YOU! I obviously agree your approach is a step forward and desired change; my main concern was how the change was going to take place and as long as you're in the frame as you say, I feel good about this!