cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
<mattip_>
see the discussion ^^^
<YannickJadoul>
I saw something there, but I don't have a lot of knowledge about macOS
<YannickJadoul>
I do have access to a new mac in the office. Mojave is the latest version, right?
<YannickJadoul>
I could test some thing tomorrow, if that helps?
<mattip_>
I think it is one back (10.14, 10.15 was just released)
<mattip_>
that would be great if you have some time
<mattip_>
I think creating a virtualenv failed
<YannickJadoul>
Ah yes, you're right. So that one's got Catalina, already. But I'll give it a try, anyway
<YannickJadoul>
To be sure: just the download from pypy.org?
<YannickJadoul>
Do you know if just replacing `<install dir>/Scripts` by `<install dir>/bin` will also work for all the other installations?
<YannickJadoul>
(I mean other things that CPython would put in Scripts/)
<mgedmin>
thank you very much for your time, arigato, and apologies for creating extra work for you
<arigato>
my anger was not directed at you :-)
<arigato>
this wheel was really missing and at some point someone else would have complained too
<kenaan>
arigo cffi/cffi eebc6733b38d /: Tweak the '-Wno-*' arguments passed to gcc during tests
<arigato>
YannickJadoul: so the git head of cibuildwheel now builds manylinux2010 wheels, and the latest release builds manylinux1, is that right?
<mgedmin>
my issue wasn't really "I need this wheel", it was more "oversight or decision? when is the Python community finally dropping support for i686 / manylinux1?"
<mgedmin>
(I suppose "technical difficulties" is a midpoint choice between oversigth and decision-to-drop)
<YannickJadoul>
arigato: Yes
mattip_ has joined #pypy
<arigato>
possibly a bad idea
<YannickJadoul>
Though you can make manylinux1 wheels by setting `CIBW_MANYLINUX_X86_64_IMAGE=manylinux1` and/or `CIBW_MANYLINUX_I686_IMAGE=manylinux1`
<mgedmin>
ooh
<arigato>
OK thanks
<YannickJadoul>
Sorry, lots of changes coming up in the next release, so the master's README's in a weird state
<mattip_>
it seems pip is smart enough to prefer "Scripts" on windows if it exists, but then defer to bin if it doesn't
<YannickJadoul>
Two more things, and we have PyPy support for Windows wheels on cibuildwheel :)
<YannickJadoul>
1) The pypy3 wheel's filename is 'spam-0.1.0-pp372-pp372-win32.whl' instead of the expected 'spam-0.1.0-pp372-pypy3_72-win32.whl'? (For
<YannickJadoul>
... For manylinux, that's 'spam-0.1.0-pp372-pypy3_72-manylinux2010_x86_64.whl', and for PyPy 2 on Windows it's 'spam-0.1.0-pp272-pypy_41-win32.whl' so that feels like a bug?
<YannickJadoul>
arigato: 2) Is there a known workaround to make the cibuilwheel PR succeed?
<arigato>
YannickJadoul: I have no idea, sorry
<kenaan>
arigo py3.6-exc-info a5983abcf08b /: close branch, ready to merge
<kenaan>
arigo py3.6 251b47698e8e /pypy/: hg merge py3.6-exc-info Generators need to store the old current 'exc_info' in a place that is visible, because in o...
<kenaan>
arigo py3.6 2a48a020ef28 /: merge heads
<mattip_>
it seems like a startup issue: something is read before it is initialized
<YannickJadoul>
It doesn't happen on AppVeyor, somehow
<mattip_>
YannickJadoul: you might be able to work around it by proactively setting the codepage to non-utf8 before startup