Release 1.12.0 Causes exit 1 on install

[DavidWylie]

Release 1.12.0 causes the following error on pip install but previous releases have been ok.

Complete output from command python setup.py egg_info:

    No working compiler found, or bogus compiler options passed to
    the compiler from Python's standard "distutils" module.  See
    the error messages above.  Likely, the problem is not related
    to CFFI but generic to the setup.py of any Python package that
    tries to compile C code.  (Hints: on OS/X 10.8, for errors about
    -mno-fused-madd see http://stackoverflow.com/questions/22313407/
    Otherwise, see https://wiki.python.org/moin/CompLangPython or
    the IRC channel #python on irc.freenode.net.)
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/setuptools/sandbox.py", line 154, in save_modules
    yield saved
  File "/usr/local/lib/python3.7/site-packages/setuptools/sandbox.py", line 195, in setup_context
    yield
  File "/usr/local/lib/python3.7/site-packages/setuptools/sandbox.py", line 250, in run_setup
    _execfile(setup_script, ns)
  File "/usr/local/lib/python3.7/site-packages/setuptools/sandbox.py", line 45, in _execfile
    exec(code, globals, locals)
  File "/tmp/easy_install-wz5r8c5j/cffi-1.11.5/setup.py", line 142, in <module>
  File "/tmp/easy_install-wz5r8c5j/cffi-1.11.5/setup.py", line 77, in ask_supports_thread
  File "/tmp/easy_install-wz5r8c5j/cffi-1.11.5/setup.py", line 59, in no_working_compiler_found
    cmdclass={
SystemExit: 1

[laurens-jan]

Same issues here. After installing setuptools and twine (pip install setuptools twine), setuptools fails.

Running python setup.py sdist fails with the non-instructive error:
ImportError: No module named setuptools File "<string>", line 1, in <module> Traceback (most recent call last): ......

For now fixing by sticking to 1.11.0:
pip install setuptools twine==1.11.0

Or in requirements.txt:
twine==1.11.0

[jamadden]

I would guess this is related to #395 which had concerns about pulling in a C dependency. There were supposed to be binary wheels available, though.

[DavidWylie]

if it helps this was acheived on the latest python:3 docker image doing a pip install of twine

[di]

Sorry about that folks, fix is in #405 Wrong issue.

[sigmavirus24]

@di I don't think this is related to #403 this is more related to #407

[di]

Oops, mixed up this issue and #403.

[di]

Some fixes for anyone experiencing this issue, in order from most ideal to least ideal:

• Switch to a non-alpine image (e.g. instead of python:3.7.0-alpine3.8 use the python:3.7.0-slim image)
• If you're stuck on an alpine-based image, run apk add --update alpine-sdk libffi-dev to install a compiler prior to installing twine
• If you can't install system-level packages, pin twine to twine<1.12 when installing

If none of these work for you: I'm curious to hear what environments you're using, please comment here.

[raiderrobert]

@di I'm currently using option 3:

pin twine to twine<1.12 when installing

But that had to do more with expediency in the mean time since we were doing an urgent release.

I'll trial the first option soon and report back with any findings.

[sigmavirus24]

@di I wonder if it makes sense to move twine check into a separate project/package that can be installed via an extra. It can register itself via entry-points the way it does today. Users would do

pip install twine[check]
twine check ...

It makes more sense to me to not have check exist by default when we haven't installed the dependencies. Then someone might do

pip install twine
twine check ...

And see some error about the fact that they need to install something else. That is less than ideal.

[di]

This should be resolved now that there's a new release of readme_renderer which removes the cmarkgfm package as a default dependency.