missing at least 3.12+ arm wheels
looking at pypi https://pypi.org/project/zstd/1.5.7.2/#files it appears that at least for linux arm there are only wheels up to 3.11. i figured i'd take a look at the workflows to see why those weren't covered in the matrix but instead found per-case it seems workflows. can this not be handled by a matrix? a matrix does end up with various exceptions due to ragged edges of the matrix, but can drastically reduce repetition (and missing wheel builds).
tl;dr
- it would be helpful to have wheels for all versions built and published
- i would be happy to help with that depending on an explanation for the present ci setup.
thanks!
Is there anything we can do to help this along? Kyle is available to assist with cleaning up the Github workflows. Preferably, CNI can help with upstream fixes rather than managing a fork to obtain the required binary wheels.
@emlowe test some arm/64 actions that builds any wheels
i see both build-wheels.yml with a matrix and also lots of other repeated workflows for specific combinations. which are used for what?
@emlowe test some arm/64 actions that builds any wheels
are you referring to this failure?
https://github.com/sergey-dryabzhinsky/python-zstd/actions/runs/16992438286/job/48174913562?pr=260#step:7:77
ValueError: 'armhf' is not a valid Architecture
or maybe this one.
https://github.com/sergey-dryabzhinsky/python-zstd/actions/runs/16993620003/job/48178860631#step:7:378
Error: '/opt/python/cp312-cp312/bin/python' executable doesn't exist in image 'quay.io/pypa/manylinux_2_24_x86_64:2022-12-26-0d38463' to build 'cp312-manylinux_x86_64'.
i would suggest we start by reverting the addition of armhf. that will allow more green ci and also avoid hiding any issues in other PRs i make.
- [x] https://github.com/sergey-dryabzhinsky/python-zstd/pull/263
armhfis not a valid arch here. https://cibuildwheel.pypa.io/en/stable/options/#archsaarch64is the 'common' meaning of arm here with linux, as i understand it.
@sergey-dryabzhinsky, would you be willing to cancel and rerun the failures on this job? https://github.com/sergey-dryabzhinsky/python-zstd/actions/runs/16995481612/job/48185051662 for me it shows a lot of the linux stuff as not having run and it would be helpful to have a reference on the latest master to compare my pr runs against.
@altendky done
do we need to be running the linux builds on both 24.04 and 20.04? it looks like 22.04 is the oldest listed ubuntu https://github.com/actions/runner-images. the builds occur inside docker via cibuildwheel. if we want testing of the wheels across various platforms then we could have a followup job that uses the already built wheels. if we want 20.04 we could work in a docker image instead of trying to get that from a github actions host.
i bring this up because it looks like all the not-running jobs are 20.04.
i would tend towards just dropping the 'older ubuntu' jobs but we could also update that to 22.04. let me know if you are comfortable having this changed and i'll make a pr.
meh, i try not to be pushy, but it's probably easier to just have a pr ready in case you agree. https://github.com/sergey-dryabzhinsky/python-zstd/pull/265
@altendky 20.04 was having lowest libc at a time . If it deprecated now then it unneeded now.
that was specifically the runner. we control the libc used to build by using the manylinux docker image via cibuildwheel. so for building, the runner host doesn't matter a whole lot.
it looks like https://github.com/sergey-dryabzhinsky/python-zstd/pull/262 fixed the 3.12/3.13 linux jobs without introducing new failures. after that i'll keep looking at other failures.
i've been fixing the build wheels workflow with the matrix. are the other workflows still used? just making wheels with 'specialized' compilation settings?
Yes, they are used. Yes they are
it looks like #262 fixed the 3.12/3.13 linux jobs without introducing new failures. after that i'll keep looking at other failures.
how does this look?
@altendky nothing really changed. No new wheels on test pypi
the job ran and succeeded:
https://github.com/sergey-dryabzhinsky/python-zstd/actions/runs/17010491011/job/48225872586?pr=262
unlike on master:
https://github.com/sergey-dryabzhinsky/python-zstd/actions/runs/17040760321/job/48303679514#step:8:380
Error: '/opt/python/cp312-cp312/bin/python' executable doesn't exist in image 'quay.io/pypa/manylinux_2_24_x86_64:2022-12-26-0d38463' to build 'cp312-manylinux_x86_64'.
the publish step, including test pypi, is skipped. presumably related to me not having permissions to the secrets (which i should not).
https://github.com/sergey-dryabzhinsky/python-zstd/blob/5fcc7829c8398f45daf2878398324d92db281b02/.github/workflows/build-wheels.yml#L247-L248
just though i'd check back on this topic. i am still interested in continuing to work through both the specific missing wheels and general help catching up with changes.
i reran the pr so there would be fresh ci: https://github.com/sergey-dryabzhinsky/python-zstd/actions/runs/17733780364/job/50390540435?pr=262
if you are uncomfortable with the pr, perhaps i can either explain it or propose an alternative approach for you to consider.
thanks!