1.10.0_1 build broke ABI w.r.t. to 1.10.0_0 builds

[traversaro]

See discussion in #50 .

@bluescarni while we discuss how to properly do the de-vendoring, I think that we can mark these packages as broken?

[traversaro]

@bluescarni while we discuss how to properly do the de-vendoring, I think that we can mark these packages as broken?

In case @conda-forge/spdlog agrees, the corresponding PR is ready to be merged at conda-forge/admin-requests#501 . Personally, I think the most important thing at the moment is fix the break that was induced by this change, then when everything is working we can think of how to properly de-vendor fmt.

[traversaro]

Hi @cav71, I may be wrong but it seems that this is more a comment on the de-vendoring in general? In that case, perhaps it could make sense to have a dedicated issue for the de-vendoring of fmt?
I am asking as this issue is dedicated just to the ABI breakage of 1.10.0_1 , and I think we can close it once we solve it, i.e. for example by merging conda-forge/admin-requests#501 .

[cav71]

My bad, sorry: I pasted it the text in the wrong thread.

[bluescarni]

@traversaro I guess this is the only viable solution at this time.

It really sucks because the status quo (before this breakage) is such that it is impossible to use the current conda pinned fmt version (9.x) together with spdlog in the same package (or within a dependency chain). I guess I'll have to go and migrate back a bunch of packages to fmt pinned to 8.x :(

[traversaro]

Perhaps while we wait for an spdlog release we could think of doing a variant of this package with non-vendored fmt, but with a lower priority w.r.t. to the abi compatible vendored fmt spdlog . I would need to think about it, but perhaps we can find a solution before the new spdlog release.

[bluescarni]

@traversaro if such a strategy worked it would be a life saver... anything I can do to help? It sounds a bit beyond my conda-fu...

[traversaro]

@traversaro if such a strategy worked it would be a life saver... anything I can do to help? It sounds a bit beyond my conda-fu...

@bluescarni can you point me to one of the packages in which you want to install spdlog 1.10 and fmt 9.0 at the same time? So that I can try to get a clear idea on this.

[kkraus14]

+1 to a variant with a track feature to weigh it down now and then consider moving to external fmt for 1.11 where we can more safely have an ABI break

[traversaro]

+1 to a variant with a track feature to weigh it down now and then consider moving to external fmt for 1.11 where we can more safely have an ABI break

The only missing piece of the puzzle for me is: how does the downstream package explictly depend on the custom variant? It may be obvious but I am not enough experienced with that.

[bluescarni]

Hi @traversaro thanks a lot for helping out...

So I have this package, heyoka, which depends on both spdlog and fmt:

https://github.com/conda-forge/heyoka-feedstock/blob/main/recipe/meta.yaml

As you can see from the recipe, I pinned spdlog to 1.10 and fmt to 8.1 in order to prevent ABI incompatibilities. So far so good.

The issue for the next version of heyoka if that one of its other dependencies, called mp++, in its latest version depends on fmt:

https://github.com/conda-forge/mppp-feedstock/blob/main/recipe/meta.yaml

The fmt version in this recipe is not pinned, so it currently depends on fmt 9.

This means that, as far as I have understood, it won't be possible to release the next version of heyoka until fmt is unbundled from spdlog, so that heyoka, spdlog and mp++ can all depend on the same version of fmt (i.e., the one globally pinned by conda-forge).

[kkraus14]

The only missing piece of the puzzle for me is: how does the downstream package explictly depend on the custom variant? It may be obvious but I am not enough experienced with that.

I've seen two different approaches to it:

1. You have a selector package, i.e. something like the arrow-cpp-proc package that has cpu and cuda variants defined via build strings. The arrow-cpp package then has a run_constrained entry on that package, i.e. https://github.com/conda-forge/arrow-cpp-feedstock/blob/main/recipe/meta.yaml#L117
2. You just use build strings, i.e. here we could have bundledfmt and extfmt in the build string and a downstream package can then have a specification like spdlog=1.10=*extfmt*

[h-vetinari]

Bear is an example that doesn't depend on fmt, but breaks.