gyp: remove support for Python 2

[cclauss]

Ironic that #2300 is about the migration from Python 2 --> 3 ;-)

Roughly corresponds with nodejs/node#36691 and nodejs/gyp-next#88

Blocked by #2318

Python 2 died one year ago so let's only support the currently supported versions of CPython:
https://devguide.python.org/versions/#versions

Removes windows-build-tools because its current release unfortunately still installs legacy Python.
felixrieseberg/windows-build-tools#206

Checklist

• npm install && npm test passes
• tests are included
• documentation is changed or added
• commit message follows commit guidelines

Description of change

[gengjiawen]

great work.

[rvagg]

So all of those changes to the .py files, are they buying us anything, or are they just intended to be hostile to laggard Py2 users?

[gengjiawen]

So all of those changes to the .py files, are they buying us anything, or are they just intended to be hostile to laggard Py2 users?

I am afraid just to drop our long commitment to the stubborn python2 user :)

[cclauss]

F-strings (the bulk of the #2318 changes) are a single instruction in Python bytecode. This makes them faster and more efficient than legacy string formatting https://www.scivision.dev/python-f-string-speed Improved readability is also a clear value.

There are plenty of versions of Node.js that legacy Python users can continue to use. I see no reason why our users should suffer with code that is slower, more difficult to read/maintain with no possibility of adding type hints just because a tiny minority choses to continue to run on an insecure platform that died on 1/1/2020. Type hints help us find bugs.

[gengjiawen]

Maybe use update-gyp.py to update the gyp part since it's more trackable.

nodejs/gyp-next#89 is on the way.

[cclauss]

Rebased after #2318 has landed.

[rvagg]

I'm not a -1 (not blocking it), just not enthusiastic enough about this to hop onto the +1 side

[mfonville]

When dropping python2 support, could you please also update the shebang to python3?
RPM builds for Atom hit this bug: atom/atom#21937

We can implement a work-around, but best would be if the shebang gets updated upstream :-)

[DeeDeeG]

Following up on what @mfonville said, Fedora has a really strict lint about Python shebangs when building rpm packages, such that #!/usr/bin/env python or #!/usr/bin/python are not valid. It has to be exactly #!/usr/bin/python2 or #!/usr/bin/python3 (Edit: #!/usr/bin/env python2 or #!/usr/bin/env python3 are allowed too). I'm not sure whether you folks would want to do exactly #!/usr/bin/python3 for all the gyp files.

If you folks do not want to update gyp's shebang lines, then for Fedora users, there are macros available in Fedora to auto-convert shebangs and satisfy the lint, or ways of disabling the lint.

[cclauss]

Brew-installed versions of Python 3 are not at /usr/bin/python3 so I would be supportive of #!/usr/bin/env python3 but not something different than that.

[mfonville]

@cclauss You are completely right. env should not be dropped, I had missed that Fedora even enforced that.
So we will find a separate workaround solution with the Fedora packaging.

Meanwhile for node-gyp, especially with this PR merged that drops python2 support, it would be appropriate to update the shebangs to python3 as recommended in the PEPs.

[cclauss]

The messages above make it seem like Fedora will accept the env approach.

[DeeDeeG]

Ah, I just tested this and you're right @cclauss.

Details for anyone who is curious (click to expand):

#!/usr/bin/env python3 is allowed. It is automatically converted to #!/usr/bin/python3, following the default policy for rpm building in Fedora 30 and newer. It doesn't error out the linter, and as mentioned above, the linting/shebang "mangling" behavior can be customized or turned off.

Here's an example of what rpmbuild does to a #!/usr/bin/env python3 shebang on Fedora 33:
mangling shebang in /[ ... ]/node-gyp/gyp/samples/samples from /usr/bin/env python3 to #!/usr/bin/python3

(That's an informational/logging line, not even an error or warning. I find Fedora's approach weird, coercing/"mangling" the shebangs to something more standardized. But it doesn't error out, so that's good. Some really core parts of Fedora are written for Python 3, such as the package manager dnf, so the chance of Fedora users having /usr/bin/python3 are nearly 100%.)

For reference, here is a link to the policy this is about. But env is okay.

https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error

[DeeDeeG]

If Python 2 support is gone, then I believe lib/find-python.js should be updated to reflect that.

[cclauss]

@DeeDeeG would you be willing to create pull requests on https://github.com/nodejs/gyp-next for the shebang (#!/usr/bin/env python/usr/bin/env python3) and on this repo for the lib/find-python.js changes?

[DeeDeeG]

Sure. @mfonville if you want to update the shebangs as @cclauss mentioned I can leave that for you, or I can do it. I'll work on lib/find-python.js first.

[mfonville]

@DeeDeeG if you could do it, please. The AC adapter of my laptop broke down, so no coding for me at the moment :-/

[ferdnyc]

Some really core parts of Fedora are written for Python 3, such as the package manager dnf, so the chance of Fedora users having /usr/bin/python3 are nearly 100%.)

FTR: Not nearly 100%, but exactly 100% — because any official distro package built with any sort of Python3 dependency will force /usr/bin/python3 to be installed.

The mangling is strict, but it's complemented by the fact that DNF/RPM are similarly much more strict than most such tools, including apt/dpkg, when it comes to dependencies. DNF won't install a package without all of its required dependencies. In fact it errs on the side of inclusion, so even optional dependencies will be installed by default. (Though it's possible to turn off optionals at install time.)

If Atom were being built as an official package, the fact that it bundles Python code but doesn't declare a Requires: config(python3) in the .spec would be flagged as a packaging error.