apache / arrow-nanoarrow

Helpers for Arrow C Data & Arrow C Stream interfaces
https://arrow.apache.org/nanoarrow
Apache License 2.0
151 stars 34 forks source link

python: Nightly wheel upload is failing #437

Closed paleolimbot closed 2 months ago

paleolimbot commented 2 months ago

After #427 we now upload wheels! This job seems to now be failing:

https://github.com/apache/arrow-nanoarrow/actions/runs/8768760925/job/24063892961#step:5:78

The issue seems to be that the version is identical:

Uploading nanoarrow-0.5.0.dev0-pp39-pypy39_pp73-manylinux_2_5_i686.manylinux1_i686.manylinux_2_17_i686.manylinux2014_i686.whl - this version already exists
Uploading nanoarrow-0.5.0.dev0-pp39-pypy39_pp73-win_amd64.whl - this version already exists
Uploading nanoarrow-0.5.0.dev0.tar.gz - this version already exists
There was a problem uploading at least 1 package

cc @jorisvandenbossche @raulcd

jorisvandenbossche commented 2 months ago

Hmm, I don't directly see an option for the command line to allow overwriting existing files (I know that for scientific python index at https://anaconda.org/scientific-python-nightly-wheels/repo, many packages use an identical dev version, but that's of course using a different tool to upload).

So I assume the only option to get it working with fury is to ensure we get unique version names ..

jorisvandenbossche commented 2 months ago

One problem is that we don't have tags on he main branch, so git describe based approaches don't work here

raulcd commented 2 months ago

On the Apache Arrow repo after bumping versions we push the dev tag: https://github.com/apache/arrow/blob/main/dev/release/post-11-bump-versions.sh#L124-L129

paleolimbot commented 2 months ago

This is all me (for managing my tags improperly!). I think ADBC rebases on the release commit, which I never quite got to. The heuristic I use for the changelog is to find the version bumping commit and use that:

https://github.com/apache/arrow-nanoarrow/blob/db6630b7770d33edc5227f60929a269a4aff8a04/dev/release/changelog.py#L43-L52

lidavidm commented 2 months ago

ADBC doesn't actually rebase on the release commit, we just have a script that manually bumps a version string in a bunch of places

paleolimbot commented 2 months ago

Git describe seems to work for ADBC:

https://github.com/apache/arrow-adbc/blob/257420a69f9215de12c8fcb8d90c95a10e510380/.github/workflows/packaging.yml#L85-L90

...so I assume I'm just putting the tag in the wrong place? The "rebase" comment is my misinterpretation of this chunk:

https://github.com/apache/arrow-adbc/blob/257420a69f9215de12c8fcb8d90c95a10e510380/dev/release/post-09-bump-versions.sh#L41-L48

jorisvandenbossche commented 2 months ago

That git describe command is not working for me locally for ADBC .. (not sure if I am doing something wrong)

jorisvandenbossche commented 2 months ago

But as @raulcd mentioned, we can probably do the same as Arrow and push a dev tag to main

paleolimbot commented 2 months ago

I'm game for either wiring up the logic in changelog.py or by pushing a dev tag (but one of you might have to point me to where this happens in the Arrow repo).

edit: 🤦 I see that Raul already linked it

lidavidm commented 2 months ago

Git describe seems to work for ADBC:

https://github.com/apache/arrow-adbc/blob/257420a69f9215de12c8fcb8d90c95a10e510380/.github/workflows/packaging.yml#L85-L90

...so I assume I'm just putting the tag in the wrong place? The "rebase" comment is my misinterpretation of this chunk:

https://github.com/apache/arrow-adbc/blob/257420a69f9215de12c8fcb8d90c95a10e510380/dev/release/post-09-bump-versions.sh#L41-L48

Hmm, that's a weird way of writing git pull --ff-only apache main I believe, given we don't make any other commits beforehand and local main shouldn't have diverged from upstream main.