install hangs forever on pypy

Issue #146 resolved
created an issue

The 3.1 release of pyobjc-core changed a subtle interaction between 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!)

Comments (14)

  1. Ronald Oussoren repo owner

    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 to explicitly fail on PyPy and will report on the problems in this issue.

  2. Ronald Oussoren repo owner

    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).

  3. Glyph reporter

    @Ronald Oussoren - I totally understand that PyObjC is not supported; it's just that a 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.

  4. Ronald Oussoren repo owner

    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 now prints a warning instead.

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

    See #146

    → <<cset 962625c1a7eb>>

  5. Glyph reporter

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

  6. Log in to comment