Updating with 7.3.0 release #1
Conversation
| version of PyPy. You can probably ignore them. | ||
| - ``pypy_73`` and ``pypy36_pp73`` (or before PyPy 7.3.0, ``pypy_41`` and | ||
| ``pypy3_71``) are the binary ABI tags for the relevant version of PyPy. | ||
| You can probably ignore them. |
There was a problem hiding this comment.
I think it would be helpful to rephrase this in terms of "python tags" and "ABI tags". The python tag is controlled by pip/setuptools and is unfortunately pp271/pp272/pp273/pp371/pp372/pp373, it should be pp27 or pp36 (only the python version, not the pypy 71/72/73 version). The ABI tag is pypy_41/pypy_73/pypy3_71/pypy3_72/pypy36_pp73.
There was a problem hiding this comment.
Happy to change this, but you know a lot more about it and might be better at phrasing it. Feel free to push some changes to my branch/fork, before merging this PR.
There was a problem hiding this comment.
Probably best to let it go as-is, since anyhow the next version of pip should change the python tag, making a mess of whatever exists now. Luckily there are not that many pypy-specific wheels out there yet
There was a problem hiding this comment.
Does that mean it would be a good idea to withhold merging/releasing pypa/cibuildwheel#185 for now, until the pip/setuptools gets changed/fixed?
There was a problem hiding this comment.
I don't know. The source of the tag creation is https://github.com/pypa/packaging. The version at HEAD in that repo is not the same as version 19.0 which is currently vendored into pip https://github.com/pypa/pip/tree/master/src/pip/_vendor/packaging. I assume the idea is that packaging 20 (to be released) will be the one used in pip 20 (to be released) but I am not sure. I wanted to get 7.3.0 out (with the new ABI tags) before they release pip20, which I think will be some time in Jan 2020.
$ ../pypy3.6-HEAD/bin/pypy3 -c"from packaging.tags import sys_tags;
print('\n'.join([str(s) for s in sys_tags() if str(s).startswith('pp')]))"
pp373-pypy36_pp73-manylinux2014_x86_64
pp373-pypy36_pp73-manylinux2010_x86_64
pp373-pypy36_pp73-manylinux1_x86_64
pp373-pypy36_pp73-linux_x86_64
pp373-none-manylinux2014_x86_64
pp373-none-manylinux2010_x86_64
pp373-none-manylinux1_x86_64
pp373-none-linux_x86_64
pp373-none-any
The new HEAD version shows
```bash
$ ../pypy2-HEAD/bin/pypy -c"from packaging.tags import sys_tags;
print('\n'.join([str(s) for s in sys_tags() if str(s).startswith('pp')]))"
pp27-pypy_73-manylinux2014_x86_64
pp27-pypy_73-manylinux2010_x86_64
pp27-pypy_73-manylinux1_x86_64
pp27-pypy_73-linux_x86_64
pp27-none-manylinux2014_x86_64
pp27-none-manylinux2010_x86_64
pp27-none-manylinux1_x86_64
pp27-none-linux_x86_64
$ ../pypy3.6-HEAD/bin/pypy3 -c"from packaging.tags import sys_tags;
print('\n'.join([str(s) for s in sys_tags() if str(s).startswith('pp')]))"
pp36-pypy36_pp73-manylinux2014_x86_64
pp36-pypy36_pp73-manylinux2010_x86_64
pp36-pypy36_pp73-manylinux1_x86_64
pp36-pypy36_pp73-linux_x86_64
pp36-none-manylinux2014_x86_64
pp36-none-manylinux2010_x86_64
pp36-none-manylinux1_x86_64
pp36-none-linux_x86_64
There was a problem hiding this comment.
OK, great; thank you for that! It's good to know, if tests soon start failing.
(Also makes me a bit happier that I chose the shortened pp27_73-manylinux_pypy_x86_64 and pp36_73-manylinux_pypy_x86_64 build identifiers for cibuildwheel :-) )
| if [ ! -f "$outdir/bin/pypy" ]; then | ||
| ln -s pypy3 $outdir/bin/pypy | ||
| fi | ||
|
|
There was a problem hiding this comment.
Hmm, I guess this is something we should do in the packaging script.
There was a problem hiding this comment.
Unless it was intentionally so so one can unpack both 2.7 and 3.x in the same directory without clashes...
|
LGTM. A few small nits, but this can probably go in as-is and we can tweak the text that no-one reads later. @antocuni should I merge it? |
Temporary, locally-built test version available at https://hub.docker.com/r/yannickjadoul/manylinux2010-pypy_x86_64
The main non-straightforward thing is the extra
pypy->pypy3symlink that was necessary, since the new PyPy releases don't provide it, but portable-pypy did.