build: prefer python 3 over 2 for configure

[sam-github]

Change python search order to python3*, then python, then python2*.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/26169/

[targos]

could you do it also for windows? the logic is in https://github.com/nodejs/node/blob/master/tools/msvs/find_python.cmd

[targos]

See the comment

node/tools/msvs/find_python.cmd

Lines 6 to 7 in 5a042a6

	:: To remove the preference for Python 2, but still support it, just remove
	:: the 5 blocks marked with "Python 2:" and the support warnings

[sam-github]

Ok. The 5th block didn't have a clear end, I removed

node/tools/msvs/find_python.cmd

Lines 85 to 97 in 5a042a6

	:: Python 2:
	:found-python2
	echo Python 2 found in %p%\python.exe
	set pyver=2
	goto :done
	:found-python
	echo Python found in %p%\python.exe
	echo WARNING: Python 3 is not yet fully supported, to avoid issues Python 2 should be installed.
	set pyver=3
	goto :done
	:done

PTAL @targos

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/26170/

[sam-github]

If someone can tell me exactly what this needs to be on Windows, I'll add it, but otherwise, I won't have the time for now, and I'll leave it (EDIT: meaning "abandon this PR") for others to pick it up.

cc: @MylesBorins

[cclauss]

LGTM -- This is music to my ears!!! The mod to configure looks appropriate to me.

I will let others judge the validity of the Windows changes but my choice would have been to simplify by first trying py on Windows.

Given the various issues with macOS Catalina in Node and in Node-gyp and given the fact that Catalina is not yet testable on Travis or GitHub Actions or Jenkins, I am not in a rush that we land this PR.

[joaocgreis]

@sam-github I pushed a fixup to your branch with the Windows changes, feel free to remove or change as needed. This won't prefer Python 3, but I don't think we need to do that. This uses Python from PATH if it is there, as has always(?) been the Windows behavior.

@cclauss adding a check for py after the PATH and before the registry would be nice (and also in node-gyp!). I might get to it, but since this works I might take a while. Would be happy to review a PR!

[sam-github]

@joaocgreis Thanks for the commit. I detangled it from my fixup, so the first commit is pure configure and yours is pure vcbuild. I made no changes (I hope!) to your code, but I rewrote the commit message to describe how it behaves on Windows, as its different from using configure.

Please take another look to ensure I got the commit description correct.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/26187/

[sam-github]

Landed in 11275dc...d1d571e

[sam-github]

I think calling this major may be incorrect. If we support both py2 and py3, then it shouldn't matter which is found since they both work.

But, I'm not sure how we get that kind of confidence.

But, on the other hand, this only applies to builds of node from source, so perhaps its not so risky?

I'd like some folks from @nodejs/tsc to weigh in. Can we land this on 13.x?

Its easily revertible if it causes problems, and also probably easily fixable.

In the meantime, I labelled it semver-major so it doesn't get pulled into 13.x and below until consideration to the impact happens.

[cjihrig]

If this is considered a semver major, does that mean it wouldn't go out in a release until after python 2 is EOL?

[sam-github]

yes

[sam-github]

But to be clear, WITHOUT this change, a build host that has only py3 would use py3. In other words, if someone builds 12.x and 13.x and is disturbed to find it used Py2 to run gyp... they should uninstall Py2.

I should also say: Unless any concerns are raised, I'm personally in favour of landing on 13.x after its been on master a week or so, just to make sure no one pulling master is affected. And if after its been on 13.x for a month or 2, it would be considered stable enough for 12.x by @nodejs/lts (I think).

[cjihrig]

I would prefer to try it in Node 13 as well due to the Python 2 EOL timing... in a way, that's kind of what the Current branch is for.

[sam-github]

OK, 3 votes for 13.x, none against, so I removed semver-major, and added dont-land-on-12.x so it doesn't hit LTS until its baked a bit on 13.x

[richardlau]

OK, 3 votes for 13.x, none against, so I removed semver-major, and added dont-land-on-12.x so it doesn't hit LTS until its baked a bit on 13.x

We have a baking-for-lts label for risky things that should wait.