Wrong PyPy Windows wheel version number

[dofuuz]

cibuildwheel generates PyPy Windows wheel with wrong version number.

https://github.com/dofuuz/python-soxr/runs/3535830912?check_suite_focus=true

11 wheels produced in 26 minutes:
  soxr-0.2.6-cp310-cp310-win32.whl
  soxr-0.2.6-cp310-cp310-win_amd64.whl
  soxr-0.2.6-cp36-cp36m-win32.whl
  soxr-0.2.6-cp36-cp36m-win_amd64.whl
  soxr-0.2.6-cp37-cp37m-win32.whl
  soxr-0.2.6-cp37-cp37m-win_amd64.whl
  soxr-0.2.6-cp38-cp38-win32.whl
  soxr-0.2.6-cp38-cp38-win_amd64.whl
  soxr-0.2.6-cp39-cp39-win32.whl
  soxr-0.2.6-cp39-cp39-win_amd64.whl
  soxr-0.2.7.dev0+gcd436f4.d20210907-pp37-pypy37_pp73-win_amd64.whl

expected: soxr-0.2.6-pp37-pypy37_pp73-win_amd64.whl

It cause error when uploading to PyPI.

https://github.com/dofuuz/python-soxr/runs/3536447175?check_suite_focus=true

Uploading soxr-0.2.7.dev0+gcd436f4.d20210907-pp37-pypy37_pp73-win_amd64.whl

  0%|          | 0.00/368k [00:00<?, ?B/s]
100%|██████████| 368k/368k [00:00<00:00, 1.08MB/s]
NOTE: Try --verbose to see response content.
HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/
'0.2.7.dev0+gcd436f4.d20210907' is an invalid value for Version. Error: Can't use PEP 440 local versions. See https://packaging.python.org/specifications/core-metadata for more information.

Github action .yaml is here:
https://github.com/dofuuz/python-soxr/blob/v0.2.6/.github/workflows/build-dist.yml

[henryiii]

To me it looks like you have a dirty directory when building PyPy, causing the version to be 0.2.7.dev0 instead of 0.2.6. Can you check a git status, or enable verbose and turn on debugging mode for your versioning tool (setuptools_scm)? You have

[build_ext]
inplace=1

Which doesn't look great, but probably not the issue here. Do you really need pp37-manylinux_i686? That is taking far, far longer than any other build, since you have to build dependencies, because your dependencies do not produce 32 bit linux wheels for PyPy. But that builds after the broken one, so don't seem to be the problem, either.

[joerick]

This looks to be more of a setuptools_scm issue, unless you can find something that cibuildwheel is doing to cause a dirty directory? Feel free to reopen if you have more information @dofuuz (git status, or enable verbose and turn on debugging mode for your versioning tool)

[Czaki]

This looks to be more of a setuptools_scm issue, unless you can find something that cibuildwheel is doing to cause a dirty directory?

There was something similar in the past #437

@dofuuz May you try if you could identify source of problem using CIBW_BEFORE_TEST: "git status"?

[QuLogic]

I spent a long time trying to figure this out for Matplotlib. The git status is clean both before and after building the wheel. I hacked up setuptools_scm in setup.py to print out git status then, and it's only dirty during build. This points to the symlinks being changed to real files, like in #437.

Comparing the Python 3.9 vs PyPy 7.3.5 builds, the output appears to differ in creating the temporary directories. On Python, the normal directory path is used, but with PyPy, the path uses the DOS 8.3 name. I assume running a copy or git clone to that directory doesn't support symlinks somehow, but I was not able to reproduce in a Windows VM.

pip is soon going to stop doing out-of-source building (pypa/pip#10495), so maybe enabling that will fix things? As I said, the source directory is clean, so building there should not mess with the version.

[Czaki]

You could try if this feature will solve this problem using PIP_USE_FEATURE environment variable.

[QuLogic]

I had already started that build in fact, and it looks to be successful: https://github.com/QuLogic/matplotlib/runs/3801482344?check_suite_focus=true#step:11:131 (no more d20211005 suffix in the version).

[dofuuz]

@QuLogic Thanks for investigating this issue. 👍

pip 21.3 was released few days ago. And in-tree builds are now the default.
So, I expect this problem is going to be fixed with next dependency update of cibuildwheel.

[dofuuz]

@henryiii @joerick Can you run update dependency action to bump pip version?

[henryiii]

No, manylinux is stuck in pypa/manylinux#1207 because TravisCI's saopaulo workers are broken and have been for about a week, and you can't pick what cluster you run on (if you find a way, then we could move forward). I've got conda-forge packages stuck too because the saopaulo workers are basically all free, because they die as soon as they need to access the internet, which then frees them up to take more jobs. (That's my guess, anyway).

The bump action has been run twice, see #881, but we need to get manylinux updated and have a consistent pip version across all platforms. Same issue with PyPy too, that needs a bump to 7.3.6.

PS: "No" as in it's already been run, and that's not the issue, that is. :)