still doesn't build on pypy3 7.0
glyph opened this issue · 7 comments
following up from #97:
Collecting git+https://github.com/python/typed_ast
Cloning https://github.com/python/typed_ast to /private/var/folders/5z/sbg483yj7031bkxcptzpyh5w0000gn/T/pip-req-build-39y_vwx6
Building wheels for collected packages: typed-ast
Running setup.py bdist_wheel for typed-ast ... error
Complete output from command /Users/glyph/.virtualenvs/tmp-57d83c9d1ed6ccb/bin/pypy3 -u -c "import setuptools, tokenize;__file__='/private/var/folders/5z/sbg483yj7031bkxcptzpyh5w0000gn/T/pip-req-build-39y_vwx6/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /private/var/folders/5z/sbg483yj7031bkxcptzpyh5w0000gn/T/pip-wheel-sxm1s6jn --python-tag pp370:
running bdist_wheel
running build
running build_py
creating build
creating build/lib.macosx-10.14-x86_64-3.6
creating build/lib.macosx-10.14-x86_64-3.6/typed_ast
copying typed_ast/conversions.py -> build/lib.macosx-10.14-x86_64-3.6/typed_ast
copying typed_ast/__init__.py -> build/lib.macosx-10.14-x86_64-3.6/typed_ast
copying typed_ast/ast3.py -> build/lib.macosx-10.14-x86_64-3.6/typed_ast
copying typed_ast/ast27.py -> build/lib.macosx-10.14-x86_64-3.6/typed_ast
package init file 'ast3/tests/__init__.py' not found (or not a regular file)
creating build/lib.macosx-10.14-x86_64-3.6/typed_ast/tests
copying ast3/tests/test_basics.py -> build/lib.macosx-10.14-x86_64-3.6/typed_ast/tests
running build_ext
building '_ast27' extension
creating build/temp.macosx-10.14-x86_64-3.6
creating build/temp.macosx-10.14-x86_64-3.6/ast27
creating build/temp.macosx-10.14-x86_64-3.6/ast27/Parser
creating build/temp.macosx-10.14-x86_64-3.6/ast27/Python
creating build/temp.macosx-10.14-x86_64-3.6/ast27/Custom
gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/acceler.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/acceler.o
gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/bitset.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/bitset.o
gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/grammar.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/grammar.o
gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/grammar1.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/grammar1.o
gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/node.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/node.o
gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/parser.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/parser.o
gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/parsetok.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/parsetok.o
gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/tokenizer.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/tokenizer.o
ast27/Parser/tokenizer.c:17:10: fatal error: 'codecs.h' file not found
#include "codecs.h"
^~~~~~~~~~
1 error generated.
error: command 'gcc' failed with exit status 1
It looks like the inclusion of codecs.h
was intended to be removed based on discussion on the previous issue?
(Same error with pypy3 7.1.1)
@glyph if you read my comment there are a lot of changes that would need to be made for typed_ast to work on PyPy (the changes in the comment are just the beginning). Deleting the codecs.h
include is not really going to get you far. I gave up around the time I made that comment because I didn't feel life vendoring half of the CPython APIs we use. However, perhaps perhaps PyPy can have an internal parser flag that gets enabled from a typed_ast
module, since it will be a while before they reach 3.8?
@ethanhs ah, I see. If it’s not worthwhile to have a tracking issue open for pypy compatibility, please feel free to close this; I was just trying to catalogue the failures I encountered trying to get pypy to work for a production codebase.
Thanks, let’s close this then.
Update for those subscribed here, re:
@ethanhs: However, perhaps perhaps PyPy can have an internal parser flag that gets enabled from a
typed_ast
module, since it will be a while before they reach 3.8?
typed_ast support in PyPy was implemented by @isidentical, see comment here:
PyPy 3.8 will have typed_ast support natively (just like CPython 3.8), !791 (merged).
PyPy 3.8 is on the horizon, but still likely several months (or more) away.
It seems that while type comment parsing is implemented, language feature versioning perhaps is not?