install hangs forever on pypy

The 3.1 release of pyobjc-core changed a subtle interaction between setup.py and distutils.sysconfig.

On Pypy, get_config_var("CFLAGS") is None, which leads to calling shlex.split(None) which hangs. Perhaps this is actually a pypy bug, but it would be nice for it to do what it used to and fail immediately. OTOH, maybe cpyext could actually make pyobjc work on pypy; I never realized the distutils integration issue was so trivial and early in the build process. (Chances are it wouldn't work but it would be nice to be able to try!)

We can't change it, it is documented behavior---actually it hangs because it's trying to read sys.stdin: https://docs.python.org/2/library/shlex.html

@Armin Rigo The thing to change on pypy would not be shlex.split, it would be making get_config_var("CFLAGS") return something. Should it be?

I should note that we spotted this quickly due to the very helpful https://requires.io - https://github.com/rackerlabs/mimic/pull/578#issuecomment-202588293

Did earlier releases of pyobjc workshop with pypy? I'd expect that it wouldn't work because pyobjc is tightly bound to CPython implementation details.

The problem goes deeper than just the distutils problem, PyPy's CPython API emulation is also missing a number of symbols that PyObjC is using.

I'm trying to get pyobjc-core to build with PyPy 5.0.1, it build passes the testsuite and the patch isn't too terrible I'll apply the patch, otherwise I'll tweak setup.py to explicitly fail on PyPy and will report on the problems in this issue.

Work-in-progress patch for getting PyPy to compile PyObjC-Core.

The patch is not complete, and is not acceptable as it is. There are still problems with incomplete CPython API support in PyPy, some of which can be worked around by tweaking the internal API of PyObjC (the lack of PySequence_Fast_ITEMS), while others are more problematic (such as the lack of PySuper_Type in PyPy's headers).

Small tweak to setup.py that explicitly bails out when building with PyPy.

The PyObjC sources use features of CPython's API that aren't present in PyPy's emulation (as of PyPy 5.0.1)

See #146

→ <<cset a40b76eecfbb>>

BTW. https://pythonhosted.org/pyobjc/install.html already says that PyObjC is not supported on PyPy.

It would be cool to run PyObjC with PyPy, but I'm not sure when I'll have time to work on that.

@Ronald Oussoren - I totally understand that PyObjC is not supported; it's just that a setup.py that fails on the compile error makes it easier for other folks (myself included) to see why, and perhaps for the pypy folks to fix it on their end. If you explicitly bail out then if PyPy adds the relevant C APIs in the future, earlier releases still won't work, even though they otherwise might be able to.

Only warn about lack of PyPy support, don't error out.

As was noted in issue #146 it's better to fail during build_ext than to explicitly bail out during the build. Therefore setup.py now prints a warning instead.

This also "fixes" a crash in setup.py when running build_ext with PyPy, the build now fails while actually compiling PyObjC's sources.

See #146

→ <<cset 962625c1a7eb>>

Thanks! Perhaps this issue should be closed now, since the named issue is fixed, and we can open a separate issue for PyPy support?

As glyph noted the actual issue is solved (fix will be in PyObjC 3.2)

I've filed #147 for adding PyPy support.

Removing version: 3.1 (automated comment)