tiledbsoma 1.16.0rc1 pre-check,py39cloud branch

[johnkerl]

Following our established procedure

single-cell-data/TileDB-SOMA#3720
[sc-63626]

Sibling of #283. Replays #276.

[jdblischak]

Need to bump somacore version

[jdblischak]

This should be fine since the linux-64 builds for R 4.4 are the problem, and those platforms aren't run in the py39cloud branch

[jdblischak]

xref: #278

[jdblischak]

And actually, given our current efforts to migrate the cloud image to R 4.4, this is a good thing we are building this cloud variant

[johnkerl]

@jdblischak I'm not sure how R 4.4 got in here

All I thought I was doing was:

• Bog-standard update of git hash for tiledbsoma;
• Include mods from Pre-check for 1.16.0 that supports C++20 (py39cloud branch) #276

I had no intention of bringing anything else in ... 👀

[johnkerl]

I thought I was beginning to get a handle on a mental model in which I

• Edit
  • recipe/meta.yaml
  • recipe/conda_build_config.yaml
  • conda-forge.yml
• Run conda smithy rerender --commit auto
• If prompted, mamba upgrade -c conda-forge conda-smithy -n base and then re-try the rerender

You comment here is on one of the 'artifact files' I didn't edit; it's unclear to me what do about where the 4.4 came from ...

[johnkerl]

I hear you saying "this is a good thing", which is grand, but I had no intent or design to do any good thing of that sort, and it unsettles me that this good thing is happening here

[johnkerl]

Am I to infer from https://github.com/TileDB-Inc/tiledbsoma-feedstock/pull/278/files that not having any version specified for r_base: within recipe/conda_build_config.yaml now means "include 4.4" when a month or two it did not? Some implicit change brought in through the ecosystem?

[jdblischak]

Am I to infer from https://github.com/TileDB-Inc/tiledbsoma-feedstock/pull/278/files that not having any version specified for r_base: within recipe/conda_build_config.yaml now means "include 4.4" when a month or two it did not? Some implicit change brought in through the ecosystem?

Exactly. The file recipe/conda_build_config.yaml is our mechanism to manually override the default pinnings from conda-forge. The pinnings are constantly evolving as new software is released. When we don't manually specify a pin in recipe/conda_build_config.yaml, we "ride the wave" of the conda-forge pins. In general this is good, because it keeps our software up-to-date with the rest of the conda-forge ecosystem. Otherwise we'd risk our users running into conda solver errors when they tried to install our conda binaries.

That is one of the big use cases for our nightly feedstock builds. While it does occasionally catch a problem with the upstream software, more often than not it identifies a problem with a recent conda-forge migration. This is ideal because we find out about it immediately instead of at release time (which is how we used to find out prior to the nightly feedstock builds).

The most recent example is the conda-forge rollout of R 4.4. This broke our nightly feedstock builds (#277), thus I manually overrode this in #278 until we can fix the build errors (#279, #280).

All that R 4.4 stuff above was for the main branch. Thus here on py39cloud, R 4.4 was added when you rerendered the feedstock (which was the correct thing to do). I was going to suppress it, but then remembered that we are trying to transition the cloud image to R 4.4, so I left it. It is passing on linux-64, so there are no build errors.

[johnkerl]

Baffled by
https://dev.azure.com/TileDB-Inc/CI/_build/results?buildId=42015&view=logs&j=a60d4a33-7c5f-58bf-6ede-6cf61ef1d926&t=516b3d9b-14d8-5583-9c60-738ad10c6805

conda_libmamba_solver.conda_build_exceptions.ExplainedDependencyNeedsBuildingError: Unsatisfiable dependencies for platform linux-64: {MatchSpec("somacore==1.0.28=pyh4471522_0")}
Encountered problems while solving:
  - package somacore-1.0.28-pyh4471522_0 is excluded by strict repo priority

-- I have never seen this before.

This was on a second attempt, so it's not a spurious fail, or a freshness-related fail 🤔

[johnkerl]

$ conda smithy rerender --commit auto
INFO:conda_smithy.configure_feedstock:Re-rendered with conda-build 25.1.1, conda-smithy 3.46.1, and conda-forge-pinning 2025.03.05.16.19.52
INFO:conda_smithy.configure_feedstock:No changes made. This feedstock is up-to-date.

[johnkerl]

I think I found the issue: https://github.com/conda-forge/somacore-feedstock now (newly) exists and is still at 1.0.26 while https://github.com/TileDB-Inc/somacore-feedstock is at 1.0.28.

[johnkerl]

Regardless we do still want our own channel as higher-pri

[johnkerl]

conda-forge/somacore-feedstock#3

[johnkerl]

#283 (comment)

[johnkerl]

Closing per our established procedure

[johnkerl]

Need to test-drive spatial dependencies for [sc-64100]

[jdblischak]

@johnkerl reminder to please pull the latest changes from py39cloud (86118da) when you prepare the update PR for 1.16.0. This time your rerendering will likely have no effect because I just did it in #287 to build r-tiledbsoma 1.15.7 for R 4.4

[johnkerl]

Re-closing. The spatialdata experiment can wait.