update TileDB-VCF to 0.29.0

[awenocur]

No description provided.

[shortcut-integration]

This pull request has been linked to Shortcut Story #41337: Update Core to 2.20.1.

[jdblischak]

Need to fix the sha256:

RuntimeError: SHA256 mismatch: '9c160f2435bff60ff53401fbb72cd9d061a8af073ab37c0e544bcf2084cfcbe7' != '25c1f2c5c8e3846ebc3de0ce7069b365dc22ffadede9036d8338a072eabc9137'

[jdblischak]

The linux-64 job is failing with the same Python 3.7 error we saw last week in TileDB-Inc/tiledbsoma-feedstock#83

include/python3.7m/Python.h:44:10: fatal error: crypt.h: No such file or directory

I think it's time to drop the Python 3.7 build just like we did for tiledbsoma-feedstock. cc @ihnorton @Shelnutt2

[Shelnutt2]

The linux-64 job is failing with the same Python 3.7 error we saw last week in TileDB-Inc/tiledbsoma-feedstock#83

include/python3.7m/Python.h:44:10: fatal error: crypt.h: No such file or directory

I think it's time to drop the Python 3.7 build just like we did for tiledbsoma-feedstock. cc @ihnorton @Shelnutt2

Lets drop it!

[ihnorton]

Re-running CI to check sc-38823

[jdblischak]

@awenocur you can drop the py37 build by deleting the following from conda_build_config.yaml and then rerendering (note that this will also add a py311 build, which should be fine)

tiledb-vcf-feedstock/recipe/conda_build_config.yaml

Lines 9 to 23 in 6eef8ee

	numpy:
	- 1.21 # [linux]
	- 1.22
	- 1.22
	- 1.22
	python:
	- 3.7.* *_cpython # [linux]
	- 3.8.* *_cpython
	- 3.9.* *_cpython
	- 3.10.* *_cpython
	python_impl:
	- cpython # [linux]
	- cpython
	- cpython
	- cpython

[ihnorton]

@awenocur please also re-render. this run failed with sc-38823, but it picked up the old build not the new one with the updated SDK dependencies.

[jdblischak]

Please rebase onto master to include 9ba78d5 from #112, which dropped the linux-64 py37 build

[jdblischak]

More conda solver errors when trying to build the Python client:

• linux-64: related to libgoogle-cloud, similar to what we are observing in tiledbsoma-feedstock (eg Troubleshoot unexpected conda solver error tiledbsoma-feedstock#92)
• win-64, osx-64, osx-arm64: related to aws-sdk-cpp, presumably because tiledb 2.20 now depends on the aws packages from conda-forge (Install the AWS SDK from conda-forge. conda-forge/tiledb-feedstock#241)

Until we move away from pyarrow 11, I suspect the conda solver errors will continue to be problematic:

tiledb-vcf-feedstock/recipe/conda_build_config.yaml

Lines 9 to 14 in 9ba78d5

	pyarrow:
	- 11.*
	pin_run_as_build:
	pyarrow:
	min_pin: x
	max_pin: x

arrow 11 is no longer receiving the conda-forge migrator updates, so it isn't built against the latest aws-sdk-cpp versions, and thus is unable to be installed in the same environment as tiledb 2.20

https://github.com/conda-forge/arrow-cpp-feedstock/blob/161d0c0ef5259f93699c4c9d0b63816a872c6d1f/conda-forge.yml#L4-L9

[ihnorton]

I believe we can fix the osx-arm64 conflict in a build-bump by making the pyarrow >= condition depend on python version.

[jdblischak]

I believe we can fix the osx-arm64 conflict in a build-bump by making the pyarrow >= condition depend on python version.

The error is:

ImportError: cannot import name 'set_timezone_db_path' from 'pyarrow.lib' (/Users/runner/miniforge3/conda-bld/tiledb-vcf_1709872988870/_build_env/venv/lib/python3.9/site-packages/pyarrow/lib.cpython-39-darwin.so)

It's unclear to me why only osx-arm64 would need a different pyarrow version for different python versions. My initial guess would be a cross-compilation problem, since osx-arm64 is the only cross-compiled job in this feedstock.

[jdblischak]

It's unclear to me why only osx-arm64 would need a different pyarrow version for different python versions.

The osx-arm64 build was fixed in in #114

In the failing build in this PR, pyarrow 11 was installed in the build env and pyarrow 15 in the host env.

In the passing build from #114, pyarrow 15 was installed in both the build and host envs.

Honestly unclear why pyarrow 11 was installed in the build env in this PR. It didn't have any minimum or maximum contraints in the build requirements, the same as in #114