Repository navigation
build fails when python3 is default python #418
Description
- python configure script crashes on python3
- getting around deps: update openssl to 1.0.1j #1 with "$python2 configure", the final step crashes which also looks to be python3 related.
Activity
Try
make PYTHON=python2.this
make PYTHON=python2would fix the./configurebut it will still break themakethere are hardcoded
pythonin v8 that does not honor this$PYTHONenvironment variable.the ArchLinux AUR package basically swapped the header of all the
.pyfiles in this fashion:prepare() { cd "${srcdir}/${pkgname}" find -type f -exec sed \ -e 's_^#!/usr/bin/env python$_&2_' \ -e 's_^\(#!/usr/bin/python2\).[45]$_\1_' \ -e 's_^#!/usr/bin/python$_&2_' \ -e "s_'python'_'python2'_" -i {} \; find test/ -type f -exec sed 's_python _python2 _' -i {} \; }Wonder if there's easier way to do this?
Something similar would have to be done on for instance FreeBSD. This has been brought up previously in the nodejs issue trackers where the conclusion was that maintaining a symlink for the user (python -> python27) was the simplest solution. I'm not super happy with that either and would like some simple detection.
I don't think python3 will be supported until gyp is out of the picture. The effort for supporting python3 would be a pretty trivial task from there.
on a couple of the build machines we take the easy path and symlink
python2to~/bin/pythonand run make withPATH=~/bin/:${PATH} make ...Another way could be changing configure from a python shebang to a shell shebang, do some simple checks for which python binary we'd like to use, then pass the rest of the configure to $PYTHON -c. It requires some minor rewriting of configure (
__filename__for instance), but it'd work. Thoughts?the problem is deeper,
pythonis hardwired into a bunch of v8 build componentsYeah, I thought 2.7.x series was a requirement (as it is for gyp/node-gyp) I wouldn't be surprised if this is closed (wontfix) by an authority.
Is this a v8 issue and not fixable from our end?
Yes, both a V8 and a gyp issue. Not much we can do about that. Closing, sorry.
Reacted by Chris Chang- addedbuildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.
on Sep 8, 2015 - added a commit that references this issue
on Mar 6, 2016 just want to +1 this also and hope it can be re-opened, as referred to by @jbergstroem when he closed my similar issue in #6249. python 3.x has been out for a while and all make scripts (
configure,makeandsudo make install) should support both python 2.7 & python 3.x (and yes, i realize part of the problem is V8 has too much old python 2.x code hardwired into it, as stated in this thread above). i have been told there are patches in the works with node-gyp to support python 3.x, and i just want to re-iterate here that this should perhaps be re-opened and node.js devs should be working with V8 devs to make sure both have an upward path for later version of python.It should be noted that the current Ubuntu LTS 16.04 is Python 3 only. I took a quick glance at the Python scripts invoked and I don't see a reason why they couldn't be written in a way that works for Python 2 and 3
@crccheck I bet there's way to install python2. As you can see above, we rely on gyp accepting python3 support before starting to converge our own toolset. We're not against supporting Python 3 – rather for – but its out of our hands at the moment. If you insist on leaning or adding valuable time, I would suggest helping to get python 3 support in gyp land; reckon there'll be feedback from upstream that needs addressing.
as stated above, the problem lies that there are sections in node-gyp and the V8 engine that depend on python2 still, and until all those are solved, we're stuck. they have said they are working on it, but keep in mind, it means coordinating with the Google V8 team re-writing their stuff also for python2 or 3, depending on what a system has.
best,
— faddah
portland, oregon, u.s.a.- added a commit that references this issue
on Feb 24, 2017 - added a commit that references this issue
on Dec 14, 2017 Another workaround is setting up a virtual environment for python2. This worked for me with conda:
conda create -n python2 python=2.7
conda activate python2
npm install