Incompatible with Python 3 about gyp HOT 17 OPEN

Patch welcome whenever you're ready with one.

any progress on this?

It's been almost 4 years. Any progress?

Аny person from google not familiar with python3. As usual one way - make 
patch myself.

This problem actual: 
http://code.google.com/p/gyp/issues/detail?id=334&thanks=334&ts=1366256817

New issue 2633 by [email protected]: v8 not complile with py3k.
http://code.google.com/p/v8/issues/detail?id=2633

Need porting v8 from obsolete python2 to new version python3.

./2to3 partitallly help, but python2 package compiler, used in v8, removed  
from python3, and automatical porting fails:


build/gyp_v8 --depth=. -Dcomponent=shared_library  
-Dsoname_version=3.17.16.2 -Dv8_target_arch=x64 -Dconsole=readline -Dwerror=
Traceback (most recent call last):
   File "build/gyp_v8", line 50, in <module>
     import gyp
   File "./build/gyp/pylib/gyp/__init__.py", line 8, in <module>
     import gyp.input
   File "./build/gyp/pylib/gyp/input.py", line 5, in <module>
     from compiler.ast import Const
ImportError: No module named 'compiler' 

Would patches need to be backwards compatible with Python2?

should be able to just delete the `compiler.` part of that.

node-gyp depends on gyp, and lots of Node modules with native dependencies use 
node-gyp to build their projects. So this actually has pretty broad 
ramifications.

I don't think I'm the right candidate to actually fix this. :( Just raising 
awareness of the scope of the issue.

I just want to be sure, what is the reason for the lack of Python 3 support?

Because as a non-Python guy, it looks really lame to me. Python 3.0 was 
released in 2008(!!). Not supporting Python 3 is like a Windows app not 
supporting Vista and above and only working with XP. It's that bad.

I checked the project members, and, man, Gyp is aparently not some guy's 
abandoned weekend project. So what gives?

I've started a petition, you can sign it there: 
https://www.change.org/petitions/google-inc-upgrade-gyp-to-support-phyton-3

What is the minimum Python version that must be supported by gyp?  The post two 
years ago at 
https://groups.google.com/d/msg/gyp-developer/tsqTJr4MMZQ/pqjY_jPSl3AJ mentions 
that the Chromium build requires Python 2.6 at minimum.  Would a patch set that 
worked unmodified on Python 2.6, 2.7, and 3.2+ be accepted?

FYI Google seems to be on the path to replace GYP with GN: 
https://code.google.com/p/chromium/wiki/gn

Does anyone know what would need to be done to get a GYP version that works 
with python3?  I'm willing to tackle the problem as long as I understand what 
needs to be done.  If all we have to do is make the GYP source code python3 
compatible then this seems feasible.

I tried this once and it really is much more complicated than you would think.  
It seems that Google is replacing gyp with GN.  The other big project I know of 
using gyp is nodejs, and I'm not sure what their plan is for the future.  In 
any event, porting it seems like a lot of work, and it is especially not worth 
it if the world is moving on to others things and if Google seems to ignore all 
discussion here.

My two cents.

Many systems will continue using gyp even in the face of GN replacing it.

It would really help out the community if gyp continued to receive support,
specifically for Python 3 compatibility.

> It would really help out the community if gyp continued to receive support, 
specifically for Python 3 compatibility.

What community/communities would benefit, specifically, by python3 
compatibility?  I think it's important to answer this question before 
proceeding.

Since I've taken a crack at porting to python3 in the past, I'll add my 
thoughts on how this should proceed.  I tried a few different ways, and I 
ultimately think this is the best path forward.

The goal should be to make incremental changes that move toward python3 
compatibility while still allowing gyp to work under python2.

The `2to3` program will do many transformations automatically, and you'll want 
to use it, because there are way too many changes necessary to make them all 
manually.  But using it on automatic mode is not going to work for you.

For instance, the following command will replace all `print` statements with 
`print` functions:

    2to3 -w -n -f print .

Unfortunately, `2to3` in its default mode will make code that runs correctly 
only on python3.  So after running the above command, you'll want to go through 
each file that was modified and add `from __future__ import print_function` at 
the top.

At this point, by far the best way to proceed would be for google to accept 
this patch upstream.  Since this is such an invasive change, it's going to be a 
chore to integrate any further upstream gyp changes unless this is merged and 
upstream cooperates.  (From the lack of response by google to this thread in 
several years, this seems unlikely, but I'd love to see it happen.  In any 
event, merging it will mean that only python versions 2.6 and higher will be 
supported by gyp, as the `print` function was introduced in 2.6.  Hence my 
question above on Aug 27, 2014.)

At this point, I would then go through each one of the possible `2to3` changes 
one by one, making each transformation into its own commit.  Since some `2to3` 
changes will make code that only works on python3, it will be helpful to make 
slight modifications to the output of the `2to3` tool each time, quite possibly 
changing gyp to use the python `six` library, which is meant for 2/3 joint 
compatibility of a single codebase.  These changes will need to be made 
manually, but at least `2to3` will recognize and mark most/all of the changes 
that need to be made.  And at every point in the commit history, it should be 
possible to keep everything working correctly under python2.

Then comes the tricky part: working on string handling such that gyp will work 
under python3.  I have a vague recollection that gyp treats strings as both 
bytestrings and user-facing strings interchangeably, and this is not going to 
fly under python3.  From looking at the code myself, it was not obvious which 
strings should be what, and where.  So some amount of understanding of the gyp 
code base is going to be necessary.

There might be some other obstacles that I have not considered, but this is 
what I would expect the general process to look like.  Godspeed to whomever is 
brave enough to take it on!

FWIW, I worked in a GYP fork which only has Ninja as the generator and works 
with Python 3 (tested on 3.4).

It's here: https://github.com/saghul/gyn

It's not fully finished (porting tests is missing), but I could build iojs with 
it: https://github.com/iojs/io.js/issues/133#issuecomment-75736337