Default Python 3 for running emsdk#273
Conversation
On macOS it's pretty common to hit a problem ``` Error downloading URL 'https://github.com/kripken/emscripten/archive/1.38.25.tar.gz': <urlopen error [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:590)> ``` When an installation is started. I.e. `./emsdk install sdk-1.38.25-64bit` - this is caused in majority of cases by some problem of openssl and python2 - (some other https downloads work just fine, not sure why GitHub is special) So this Pull Request will default Python to Python 3, for running `emsdk`
|
Thanks @trzecieu! Is python3 always present on macOS? On linux it sometimes is not, which is why we have an indirection in emscripten, python_selector. Here it is used in emcc for example: https://github.com/emscripten-core/emscripten/blob/incoming/emcc that script should run in both python2 and 3. Then the selector can force a specific version (I think emscripten's doesn't do that yet though). Maybe that's the safest thing to do here as well? |
|
Good point with python selector, I've made some improvement to that.
Will call
|
|
Thanks @trzecieu, looks good! Regarding testing, I think our current ones are enough after the recent improvements. We test |
Addresses emscripten-core/emscripten#8792 I've found what's the reason of the strange behaviour of last changes (#273). In order to reproduce this problem it's needed: To don't have python3 installed in system To have pyenv with installed at least one version from each family, like: pyenv install 3.7.0 pyenv install 2.7.15 To activate a version from python2 pyenv local 2.7.15 Then we have a strange situation that python3 is available as a command, but it's just a mock for pyenv: ➜ pyenv versions system * 2.7.15 (set by /home/trzeci/Projects/emsdk/.python-version) 3.7.0 ➜ which python3 ~/.pyenv/shims/python3 ➜ python3 --version pyenv: python3: command not found The `python3' command exists in these Python versions: 3.7.0 ➜ ./emsdk --help pyenv: python3: command not found The `python3' command exists in these Python versions: 3.7.0 As you see in an example above I didn't even call emsdk script, just tried to execute python3 --version and I've got exactly the same error. The problem of pyenv is that even if python3 isn't active it's available in the system PATH. Calling ./emsdk --help get's the same error, as python3 was used. At the moment this entirely breaks logic in python_selector and in pyenv working command is indistinguishable from stub python command. @kripken: A couple of ways to go from here: revert logic of python_selector and advertise mac users to use python3 keep logic and advertise pyenv users to use python3 This PR: extend logic of python_selector by checking if found python command is valid (for the instance by calling python --version), this will filter out false positive matches that coming from pyenv After patch: ➜ pyenv versions system * 2.7.15 (set by /home/trzeci/Projects/emsdk/.python-version) 3.7.0 ➜ which python3 ~/.pyenv/shims/python3 ➜ python3 --version pyenv: python3: command not found The `python3' command exists in these Python versions: 3.7.0 ➜ ./emsdk --help emsdk: Available commands: emsdk list [--old] [--uses] - Lists all available SDKs and tools and their current installation status. With the --old .... As you can see python3 --version command fails as it was, but that's expected behaviour. What's important is that ./emsdk --help gets executed as python_selector recognizes a stub.
This change moves the python code for emsdk into a file ending in .py. This script is then run via emsdk.bat on windows or emsdk (a shell script) on non-windows. This avoid the #!/bin/sh at the top of the python script and the "exec" hack on the first line that re-runs it under python. Hopefully this preserves the intent of #273 without jumping through so many hoops.
This change moves the python code for emsdk into a file ending in .py. This script is then run via emsdk.bat on windows or emsdk (a shell script) on non-windows. This avoid the #!/bin/sh at the top of the python script and the "exec" hack on the first line that re-runs it under python. Hopefully this preserves the intent of #273 without jumping through so many hoops.
This change moves the python code for emsdk into a file ending in .py. This script is then run via emsdk.bat on windows or emsdk (a shell script) on non-windows. This avoid the #!/bin/sh at the top of the python script and the "exec" hack on the first line that re-runs it under python. Hopefully this preserves the intent of #273 without jumping through so many hoops.
This change moves the python code for emsdk into a file ending in .py. This script is then run via emsdk.bat on windows or emsdk (a shell script) on non-windows. This avoid the #!/bin/sh at the top of the python script and the "exec" hack on the first line that re-runs it under python. Hopefully this preserves the intent of #273 without jumping through so many hoops.
This change moves the python code for emsdk into a file ending in .py. This script is then run via emsdk.bat on windows or emsdk (a shell script) on non-windows. This avoid the #!/bin/sh at the top of the python script and the "exec" hack on the first line that re-runs it under python. Hopefully this preserves the intent of #273 without jumping through so many hoops.
This change moves the python code for emsdk into a file ending in .py. This script is then run via emsdk.bat on windows or emsdk (a shell script) on non-windows. This avoid the #!/bin/sh at the top of the python script and the "exec" hack on the first line that re-runs it under python. Hopefully this preserves the intent of #273 without jumping through so many hoops.
…loads Add prerelease label to the emsdk manifest
On macOS it's pretty common to hit a problem
When an installation is started. I.e.
./emsdk install sdk-1.38.25-64bit- this is caused in majority of cases by some problem of openssl and python2 - (some other https downloads work just fine, not sure why GitHub is special)So this Pull Request will default Python to Python 3, for running
emsdk