Incompatible with Python 3

[GoogleCodeExporter]

When does the problem occur?
The problem occurs when a user attempts to compile GYP with Python 3.0.x.

What is the expected output? What do you see instead?
Rather than a properly compiled GYP, Python outputs a plethora of errors, 
mostly syntactical.

What version of the product are you using? On what operating system?
GYP: Revision 520
OS: Windows 7 Ultimate RC1 x64
Python: Python 3.0.1 AMD64

Please provide any additional information below.
I am almost done updating the source for Python 3.

Original issue reported on code.google.com by techsoftadvanced on 17 Jun 2009 at 8:52

[GoogleCodeExporter]

Patch welcome whenever you're ready with one.

Original comment by sgk@chromium.org on 6 Aug 2009 at 6:25

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

any progress on this?

Original comment by jeroen.j...@gmail.com on 15 Oct 2011 at 11:14

[GoogleCodeExporter]

It's been almost 4 years. Any progress?

Original comment by beatgam...@gmail.com on 26 Mar 2013 at 8:53

[GoogleCodeExporter]

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

Original comment by perestor...@gmail.com on 17 Apr 2013 at 8:39

[GoogleCodeExporter]

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

New issue 2633 by perestoronin@gmail.com: 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' 

Original comment by perestor...@gmail.com on 18 Apr 2013 at 3:49

[GoogleCodeExporter]

Would patches need to be backwards compatible with Python2?

Original comment by beatgam...@gmail.com on 19 May 2013 at 4:05

[GoogleCodeExporter]

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

Original comment by alex.hel...@gmail.com on 2 Mar 2014 at 6:51

[GoogleCodeExporter]

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.

Original comment by konklone on 10 May 2014 at 5:11

[GoogleCodeExporter]

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?

Original comment by herzscha...@gmail.com on 26 Jul 2014 at 10:04

[GoogleCodeExporter]

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

Original comment by neuroflo...@gmail.com on 14 Aug 2014 at 7:43

[GoogleCodeExporter]

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?

Original comment by j...@garrison.cc on 27 Aug 2014 at 6:57

[GoogleCodeExporter]

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

Original comment by saghul on 28 Aug 2014 at 8:00

[GoogleCodeExporter]

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.

Original comment by neuros...@gmail.com on 23 Feb 2015 at 3:18

[GoogleCodeExporter]

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.

Original comment by j...@garrison.cc on 23 Feb 2015 at 7:46

[GoogleCodeExporter]

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.

Original comment by andrew.p...@gmail.com on 23 Feb 2015 at 10:36

[GoogleCodeExporter]

> 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!

Original comment by j...@garrison.cc on 24 Feb 2015 at 1:40

[GoogleCodeExporter]

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

Original comment by saghul on 24 Feb 2015 at 11:05