Closed jdblischak closed 1 month ago
Ugh. More conda solver errors. Same thing happened on my fork after syncing main this morning. The conda solver errors are sparse, but given that the only passing build is the one that pins old versions, it's almost certainly due to one of the various in-progress conda-forge migrations.
Restarted the failed builds š¤
@jdblischak there's a 1.0.19 already -- my apologies for not letting you know ... I'll put up the somacore-feedstock PR ...
I restarted the osx-64 build again. I don't understand why it is the only one with a solver error. I confirmed that the last successful osx-64 nightly from Thursday 9/27 installed pyarrow 17, which is the latest version, and already has all the latest migrations.
Looks like now r-tiledbsoma has the solver error. But it too installs r-arrow/libarrow 17, so this shouldn't be a problem.
@jdblischak is this b/c https://anaconda.org/conda-forge/r-tiledb/files only has 0.30.0?
is this b/c https://anaconda.org/conda-forge/r-tiledb/files only has 0.30.0?
I don't think so. r-tiledb 0.30.0 satisfies the current requirements
I specifically tested the ability of the Python builds to solve by disabling the R builds on my fork. The py3/py310/py311 builds all solved on osx-64.
https://github.com/jdblischak/tiledbsoma-feedstock/tree/nightly-troubleshoot https://dev.azure.com/jdblischak/feedstock-builds/_build/results?buildId=975&view=results
So the current solver error is limited to the specific case of r-tiledbsoma on osx-64 š¤·
Updated for current somacore requirement of 1.0.20 (https://github.com/single-cell-data/TileDB-SOMA/pull/3120)
Also curious to see if osx-64 conda solver error has been resolved by time
@johnkerl I fixed the osx-64 build! I did it by pinning libtiledb to 2.26.1 during the libtiledbsoma build. This allows r-tiledbsoma to be built against 2.26.1. But then at runtime it can be installed with 2.26.2 (I confirmed this via the recipe test). We can remove this workaround when we migrate to 2.27.
Let's merge so that we can fix the nightly builds and also prepare for 1.14.3
@jdblischak 1.14.3 is R-only and I don't see a need for Conda feedstock ... cc @mojaveazure
I agree with @johnkerl; 1.14.3 does not need a Conda release. It's already up on R-universe which is all we need for the purposes of 1.14.3
@johnkerl @mojaveazure sounds good to me. I'm glad I didn't ask about 1.14.3 first, since seeing that release finally inspired the workaround I just merged š
Confirmed that nightly feedstock builds are once again passing
https://github.com/TileDB-Inc/tiledbsoma-feedstock/commit/b3fd6779ec797492691edfe69ddd00e787b31998 https://dev.azure.com/TileDB-Inc/CI/_build/results?buildId=40977&view=results
Closes #204
xref: https://github.com/TileDB-Inc/tiledbsoma-feedstock/issues/204#issuecomment-2380870438
This is a temporary workaround to accommodate the new somacore APIs introduced in https://github.com/single-cell-data/TileDB-SOMA/pull/3078.
While we could obviously imagine a more complex setup that extracts the current version of somacore from
setup.py
, I instead decided to keep this simple since this is the first time we've run into this particular problem (or at least the first in my recent memory). If new somacore APIs in the dev version start causing more frequent failures in the nightly feedstock builds, then we can revisit this to make it more robust.Tested locally: