search

TileDB-Inc / tiledbsoma-feedstock

A conda-smithy repository for tiledbsoma.
BSD 3-Clause "New" or "Revised" License
3 stars 3 forks source link

tiledbsoma 1.11.2 #157

Closed johnkerl closed 4 months ago

johnkerl commented 4 months ago

Following our established procedure

jdblischak commented 4 months ago

Surprisingly the osx-* builds passed but the linux-64 Python builds failed to obtain the version in this setup where RELEASE-VERSION is artificially created

https://github.com/TileDB-Inc/tiledbsoma-feedstock/blob/f537d2dbc8d7e195dac350578fd8b0ca031cd67a/recipe/build-tiledbsoma-py.sh#L7

Here's the traceback:

  File "/home/conda/feedstock_root/build_artifacts/tiledbsoma_1716331838735/work/apis/python/version.py", line 275, in get_version
    version = get_git_version()
              ^^^^^^^^^^^^^^^^^
  File "/home/conda/feedstock_root/build_artifacts/tiledbsoma_1716331838735/work/apis/python/version.py", line 223, in get_git_version
    latest_tag = get_latest_remote_tag(remote)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/conda/feedstock_root/build_artifacts/tiledbsoma_1716331838735/work/apis/python/version.py", line 133, in get_latest_remote_tag
    raise RuntimeError(f"No tags found in remote {remote}")
RuntimeError: No tags found in remote origin
error: subprocess-exited-with-error

This error is surprising given the recent updates to build from an sdist that led to closing https://github.com/single-cell-data/TileDB-SOMA/issues/2588

johnkerl commented 4 months ago

cc @ryan-williams

johnkerl commented 4 months ago

@jdblischak @ryan-williams I think this may be involved:

jdblischak commented 4 months ago

I was able to build it locally from the 1.11.2 GitHub release tarball using Python 3.9:

mamba create --yes -n test-soma python=3.9 pip
mamba activate test-soma

wget https://github.com/single-cell-data/TileDB-SOMA/archive/refs/tags/1.11.2.tar.gz
tar xzf 1.11.2.tar.gz
cd TileDB-SOMA-1.11.2/

git status
## fatal: not a git repository (or any of the parent directories): .git

cd apis/python/
echo "1.11.2" >> RELEASE-VERSION
python -m pip install . -vv

This of course isn't identical to the conda build setup (since I didn't pre-install libtiledb or libtiledbsoma), but I don't think that should affect the logic of version.py.

jdblischak commented 4 months ago

Also, @johnkerl, how are you preventing the Python 3.12 variants from being added during the rerendering like they are in the nightly-build branch, eg 878194b1b6897a0f7a38c32c36a019b666e82799?

johnkerl commented 4 months ago

Also, @johnkerl, how are you preventing the Python 3.12 variants from being added during the rerendering like they are in the nightly-build branch, eg https://github.com/TileDB-Inc/tiledbsoma-feedstock/commit/878194b1b6897a0f7a38c32c36a019b666e82799?

@jdblischak I'm not aware that I'm doing any preventing -- am I doing something wrong that I'm not aware of? Am I doing something right that I'm not aware of?

jdblischak commented 4 months ago

am I doing something wrong that I'm not aware of?

My only guess was that maybe you edited conda_build_config.yaml like I had yesterday (https://github.com/TileDB-Inc/tiledbsoma-feedstock/issues/153#issuecomment-2123363407) but then didn't add and commit the file. A quick git status should confirm or deny this possibility

Am I doing something right that I'm not aware of?

If my above guess is wrong, then don't change anything! :-) You might have a slightly older conda-smithy installed locally, but we don't want those Python 3.12 variants anyways.

ryan-williams commented 4 months ago

Previous build seems to have failed with:

RuntimeError: SHA256 mismatch: 'e3933c7d7b3d8df59a40ed7833fb20774917f531a915debc76abb569e958a421' != 'e3933c7d7b3d8df59a40ed7833fb20774917f531a915debc76abb569e958a421 - 0001-version-py-workaround-1-11-2.patch'

link

The SHA parts match, but the right side contains an extra - 0001-version-py-workaround-1-11-2.patch 🤔

jdblischak commented 4 months ago

The SHA parts match, but the right side contains an extra - 0001-version-py-workaround-1-11-2.patch 🤔

@ryan-williams See my comment above, https://github.com/TileDB-Inc/tiledbsoma-feedstock/pull/157#discussion_r1612269225, about jinja2 not being that smart. This confirms my understanding. It has no understanding of the YAML sections, but is simply applied line by line. So what happened was that the field patches: was removed from the linux-64 builds (since [osx and not arm64] evaluates to false on a linux-64 build), so the following line with the path to the patch file looked like it belonged to the field sha256, and hence the failure.

johnkerl commented 4 months ago

about jinja2 not being that smart

For my future reference: this means operationally: if some yaml file has

foo: bar # [baz]
    quux # [xyzzy]

this is not good -- such lines need to be like

foo: bar #[baz]
    quux #[baz]

where the baz thing need to evaluate to true or false for each #-tagged line that the author thinks of as belonging together

johnkerl commented 4 months ago

Post-merge CI link FYI: https://github.com/TileDB-Inc/tiledbsoma-feedstock/runs/25352784338

johnkerl commented 4 months ago

... success!! :)

Now I'll monitor

https://anaconda.org/tiledb/libtiledbsoma/labels https://anaconda.org/tiledb/tiledbsoma-py/labels https://anaconda.org/tiledb/r-tiledbsoma/labels

to verify in the next hour or two that 1.11.2 artifacts arrive. This will prove we've gotten the artifact-creation issue from this release, confined to this release.

johnkerl commented 4 months ago

Many thanks @jdblischak and @ryan-williams !!!