<antocuni>
arigo: what is the strategy adopted by cffi to prevent pip install -U cffi to work on top of pypy?
<arigo>
antocuni: there's lib_pypy/cffi.egg-info/, but I don't know if there is another hack in addition to that
<antocuni>
yeah, I knew about the egg-info hack, but I think this alone does not prevent pip install -U cffi to try to install a newer version
<arigo>
ah, setup.py in the cffi repo hacks
<arigo>
search for the bool variable "cpython"
<antocuni>
ah, good
<antocuni>
I think we'll need something like that for hpy
<antocuni>
so basically, on PyPy it installs only the python modules but not the _cffi_backend
<arigo>
I think not even the python modules
<arigo>
it installs nothing on pypy
<antocuni>
ah right, I misread
<antocuni>
but pypy will still think it installed a newer version of cffi
<arigo>
yes
<antocuni>
uhm, I wonder whether this is a good strategy for hpy then
<antocuni>
it will cause troubles if people thinks they successfully installed a newer hpy but actually they didn't
<arigo>
if you have pure python modules that have some flexibility w.r.t. the builtin extension module, it's more work but probably worth it
<antocuni>
probably it's just better to make setup.py to fail if you are not on cpython
<arigo>
yes, or that
<arigo>
the problem is that many other modules on pypi have cffi as a dependency
<arigo>
so that hack at least makes the dependency be basically ignored
<antocuni>
I'm confused. With the egg-info hack, pip will think that cffi is already installed on pypy, so if package 'foo' declares install_requires=['cffi'], 'pip install foo' should NOT try to install cffi, should it?
<antocuni>
the problem arises only if you install_requires=['cffi>=X'] ?
<arigo>
I think the problem is if you use some pip options to require it to upgrade all dependencies
<antocuni>
ah
<antocuni>
it's also worth noting that at the moment hpy breaks the API every other day, so for now the only reasonable approach is to depend on specific versions like hpy==0.0.2
<antocuni>
I suppose that for now bailing out of setup.py if sys.implementation!='cpython' is a reasonable approach, and we can think of more proper fixes in the future
<arigo>
maybe only if the version of the setup.py is different from the version actually from the pypy
<antocuni>
uhm, maybe
<antocuni>
although it should never happen that pip tries to re-install it