You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
configure fails on linux for distributions using python 3 as default #9512
Platform: Linux manjaro-vm 4.8.5-2-MANJARO deps: update openssl to 1.0.1j #1 SMP PREEMPT Sun Oct 30 11:26:24 UTC 2016 x86_64 GNU/Linux
Subsystem:
Currently the configure script executes via "python", this works perfectly fine on systems that use python 2.x as their default python but it fails on systems that use python 3.x. Would it be possible/feasible to adjust it to execute via "python2" instead of "python"? Alternatively an updated configure script that works on 2.x and 3.x python would be good.
Python 3 error when trying to run configure:
Is there possibly just a missing module for python3?
This also applies to Arch Linux on which python is actually python3. I think it'd be great if we could apply __future__ and friends to support both versions.
That won't help. configure does import gyp and gyp does not pretend to be python3-compatible. Changing the shebang to python2 breaks systems with no python2 binary. I think that includes OS X.
Indeed, macOS has no python2, only python2.6 and python2.7. The version from homebrew does feature all the symlinks including python2, but I'm not sure we can require that.
There's a bunch of issues in the node-gyp repo that are similar to this. Unfortunately, the conclusion that @silverwind mentioned is likely what we can expect; upstream gyp won't get ported to python 3.
manjaro is based on arch linux and it has python2 and python2.7 links
This should be the same for arch linux but i'm not sure about other linux distributions.
For now I run the configure script directly via python 2.x.
Would it be possible to at least add a check for the python version and show an error message if python3 is detected with an advise to run the script via python2?
I don't think so. The python interpreter will throw syntax errors before the script even gets a chance to run.
The only way to work around that is to split off the main configure script into a separate script and leave only a loader stub that is legal python 2 + 3 but that seems like overcomplicating things when the python 2 prerequisite is listed in BUILDING.md.
I think it should be possible to make the file parseable in Python 3 and print a error when python >= 3. This should work as long as Python does not evaluate import before execution.
For the except issue in the original post, we can apply this workaround.
We demand specifically python 2.7, and then do #!/usr/bin/env python2.7, or
We put some logic like this at the top of the script:
#!/usr/bin/env sh
# Find a python 2 executable:
python_executable="`which python2"
if [ -z "$python_executable" ]; then
python_executable="`which python2.7`"
fi
if [ -z "$python_executable" ]; then
python_executable="`which python2.6`"
fi
if [ -z "$python_executable" ]; then
printf 'Error: could not find python 2 executable\n' >&2
exit 1
fi
# Copy the remainder of this script (which is python) to a new file and execute it with
# python instead of sh:
tmpfile="`mktemp`"
cat "$0" | tail -n +22 > "$tmpfile"
chmod +x "$tmpfile"
exec "$python_executable" "tmpfile" $@
Αnother option is to special-case MacOS, doing something like:
case `uname` in
darwin) python_executable="`which python2.7`" ;; # Or whatever uname returns on OS X; I don't have a live system handy.
*) python_executable="`which python`";;
esac
@zenhack generally good ideas, but I think the current solution is good enough as the user will know what to do from the error message. Spawning another python child process doesn't seem like the cleanest solution to me.
There are a whole bunch of other python scripts in the tree that also hard-code the name of the python executable, so they'd all have to be run with python2, and it isn't entirely straightforward to do that short of patching the source tree, since they aren't invoked directly by the user. Here's a list:
I agree the solution I proposed isn't pretty, and I wouldn't want to apply it to many files. It also looks like a lot of these are in dependencies that node pulls in in-tree? Probably don't want to be patching those.
This probably ought to be re-opened, since the problem persists. I don't have another solution immediately popping into my head, but will think on the matter.
> PYTHON=/usr/bin/python2 ./configure
Please use either Python 2.6 or 2.7
> uname -a
Linux zeno 4.4.45-1-MANJARO #1 SMP PREEMPT Thu Jan 26 11:32:11 UTC 2017 x86_64 GNU/Linux
If ./configure were to create a symlink called python that pointed towards whatever was used to run it, and were to prepend the directory containing it to the path, then that would work right?
So this was implemented in #16058, so this should now finally work without having to set PYTHON, even if your python is a python3 (as long as you have a python2 on your system).
Activity
silverwind commentedon Nov 8, 2016
This also applies to Arch Linux on which
pythonis actuallypython3. I think it'd be great if we could apply__future__and friends to support both versions.bnoordhuis commentedon Nov 8, 2016
That won't help. configure does
import gypand gyp does not pretend to be python3-compatible. Changing the shebang to python2 breaks systems with no python2 binary. I think that includes OS X.silverwind commentedon Nov 8, 2016
Indeed, macOS has no
python2, onlypython2.6andpython2.7. The version from homebrew does feature all the symlinks includingpython2, but I'm not sure we can require that.As for gyp: There's https://bugs.chromium.org/p/gyp/issues/detail?id=36, but it's unlikely gyp will ever gain support for Python3 as it's pretty much a dead project from what I understand.
jbergstroem commentedon Nov 8, 2016
There's a bunch of issues in the node-gyp repo that are similar to this. Unfortunately, the conclusion that @silverwind mentioned is likely what we can expect; upstream gyp won't get ported to python 3.
shannon-nii commentedon Nov 9, 2016
manjaro is based on arch linux and it has python2 and python2.7 links
This should be the same for arch linux but i'm not sure about other linux distributions.
For now I run the configure script directly via python 2.x.
Would it be possible to at least add a check for the python version and show an error message if python3 is detected with an advise to run the script via python2?
bnoordhuis commentedon Nov 9, 2016
I don't think so. The python interpreter will throw syntax errors before the script even gets a chance to run.
The only way to work around that is to split off the main configure script into a separate script and leave only a loader stub that is legal python 2 + 3 but that seems like overcomplicating things when the python 2 prerequisite is listed in BUILDING.md.
silverwind commentedon Nov 9, 2016
I think it should be possible to make the file parseable in Python 3 and print a error when
python >= 3. This should work as long as Python does not evaluateimportbefore execution.For the
exceptissue in the original post, we can apply this workaround.kalrover commentedon Nov 17, 2016
Can you guys help me check my first PR on node. If there is any problems, let me know.
zenhack commentedon Nov 28, 2016
A couple ideas:
#!/usr/bin/env python2.7, or(1) is certainly simpler.
zenhack commentedon Nov 28, 2016
Αnother option is to special-case MacOS, doing something like:
silverwind commentedon Nov 30, 2016
This is fixed by #9657.
@zenhack generally good ideas, but I think the current solution is good enough as the user will know what to do from the error message. Spawning another python child process doesn't seem like the cleanest solution to me.
zenhack commentedon Nov 30, 2016
So, this actually does't fix the problem:
There are a whole bunch of other python scripts in the tree that also hard-code the name of the python executable, so they'd all have to be run with python2, and it isn't entirely straightforward to do that short of patching the source tree, since they aren't invoked directly by the user. Here's a list:
The Archlinux PKGBUILD just applies a sed command to the whole source tree:
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/nodejs#n27
I agree the solution I proposed isn't pretty, and I wouldn't want to apply it to many files. It also looks like a lot of these are in dependencies that node pulls in in-tree? Probably don't want to be patching those.
This probably ought to be re-opened, since the problem persists. I don't have another solution immediately popping into my head, but will think on the matter.
7 remaining items
gunar commentedon Feb 14, 2017
For future reference, here's how I got it to work on Manjaro (~Arch):
Then I run tests with
(credits go to @zenhack)
jbergstroem commentedon Feb 14, 2017
@gunar: try
PYTHON=/usr/bin/python2 ./configureinstead.silverwind commentedon Feb 14, 2017
@jbergstroem maybe we should add this info on the error print?
node/configure
Line 5 in 76ba3bf
jbergstroem commentedon Feb 14, 2017
@silverwind sounds good to me!
gunar commentedon Feb 14, 2017
@jbergstroem your method did not work :-(
But thanks!
silverwind commentedon Feb 14, 2017
Hmm, where's this
PYTHONvariable actually documented? Can't find it:https://docs.python.org/3.7/using/cmdline.html#environment-variables
jbergstroem commentedon Feb 16, 2017
Sorry; its used in
Makefile.silverwind commentedon Feb 16, 2017
So we need to suggest
PYTHON=path maketoo, right?jbergstroem commentedon Feb 16, 2017
No; passing
PYTHON=pathtoconfigureshould write it toconfig.mkwhich gets included inMakefile. I was just providing a poor example.silverwind commentedon Feb 16, 2017
Alright, so
PYTHON=/usr/bin/python2 /usr/bin/python2 configure? 😆silverwind commentedon Feb 16, 2017
Nevermind, I see
'PYTHON': sys.executableis already handed down. I'll land #11375 later as-is.Siecje commentedon Oct 23, 2017
EDIT: I had a problem but when I updated to the latest 8.7.0 code it works.
gibfahn commentedon Oct 23, 2017
So this was implemented in #16058, so this should now finally work without having to set
PYTHON, even if yourpythonis apython3(as long as you have apython2on your system).