Delay fmt migration

[jdblischak]

The strategy in #83 failed because the recipe uses pin_subpackage(). Thus even though a libtiledbsoma variant built against fmt 9 was uploaded, the conda solver does not even consider it because the tiledbsoma-py binaries are tied to an exact build of libtiledbsoma (the fmt 10 variant). Since there is only one tiledbsoma-py 1.7.1 py39 variant, the new fmt 9 variant is excluded

wget https://anaconda.org/tiledb/tiledbsoma-py/1.7.1/download/linux-64/tiledbsoma-py-1.7.1-py39h1dd0e15_0.conda
cph extract tiledbsoma-py-1.7.1-py39h1dd0e15_0.conda
grep libtiledbsoma tiledbsoma-py-1.7.1-py39h1dd0e15_0/info/recipe/meta.yaml
##     - libtiledbsoma 1.7.1 h5723a24_0
##     - libtiledbsoma 1.7.1 h5723a24_0

Simply bumping the build number would be too unreliable. This is because the fmt pin only affects the hash of the libtiledbsoma binary (pins inserted into the run requirements of the rendered recipe do not change the build hash). Thus for each Python variant, it would be a race condition to see which was uploaded to anaconda.org first, the one linked to libtiledbsoma+fmt9 or libtiledbsoma+fmt10.

Note that using pin_subpackage() in this multi-output recipe is a hard requirement. Otherwise the solver can choose to install an existing libtiledbsoma over the local one at build and/or runtime (and we have observed this in the past).

Given the difficulty of trying to build different variants of libtiledbsoma, I have reverted the pins to fmt 9 and spdlog 1.11. This matches the feedstock prior to the 1.7.1 update in #82. This will eventually cause other solver issues as conda-forge continues to migrate to fmt 10, but we can troubleshoot this in the future.

[johnkerl]

[sc-41243]

[shortcut-integration[bot]]

This pull request has been linked to Shortcut Story #41243: tiledbsoma 1.7.1.