Proposal: drop support for Python 2

[cclauss]

Is your feature request related to a problem? Please describe.
Python 2 went EOL on 1/1/2020 and we receive no more support from the Python Core Team after Python 2.7.18 even for known security issues. Node.js and Node-gyp work with both Python 2 and Python 3. Should we drop support for Python 2 in Node.js 14? If not now, when?

Please describe the problem you are trying to solve.

Describe the solution you'd like
Encouraging users to continue to use Python 2 exposes them to unnecessary security risks. Supporting both Python 2 and Python 3 make it harder to diagnose problems and requires much more hardware, time, power, complexity to test on multiple platforms. In some cases we have already stopped testing on legacy Python while claiming that we still support it.

Describe alternatives you've considered
Please describe alternative solutions or features you have considered.
Waiting.

[richardlau]

I suggested it in nodejs/build#2168 but there wasn’t much enthusiasm for doing so.

[mscdex]

I think the other thing that would need to be kept in mind is if there would be a minimum Python 3 version/branch and if supported platforms have that particular Python 3 version/branch (easily) available (e.g. from official package repositories).

[cclauss]

Python 3.5, 3.6, 3.7, and 3.8 until September 2020 when 3.5 reaches end of life.
https://devguide.python.org/#status-of-python-branches

[mmarchini]

If we do decide to drop Python 2 and support only Python 3, we're talking about dropping it fully only in April 2023, because we're not dropping it for Node.js v14 and we'll need to keep supporting (at least in that release line) it until v14 goes EOL.

I'd be more interested in removing Python as a dependency if possible, as personally I find the Python 2/3 discussion in the project very distracting (and I don't see it going away anytime soon, even after Python 2 officially goes EOL). I guess the main issue is gyp requires Python, especially for native modules, which means we can't effectively drop it anytime soon (same reason as described above). Hopefully moving core's build toolchain from gyp to cmake can reduce our dependency on Python though.

[sam-github]

Gyp (the Python version) could be dropped if https://github.com/indutny/gyp.js/ was completed, any takers?

I think 14.x should prefer using Python 3 when searching (over Python 2), but I don't think we should delete/break support for it until:

1. Versions of node/npm/node-gyp that prefer Python 3 have been released for a while.
2. Maintenance of Python 2 compatibility become a burden.

1. I believe is not planned until the next npm major, @nodejs/npm and @nodejs/node-gyp -- can you comment on the plans for that?

2. is a bit subjective.... as @cclauss has done the lion's share of the support for that, he might feel it has already been reached, but I think things are pretty stable at this point, and issues are not arising so often.

[mmarchini]

Seems like gyp.js for native modules and cmake for core would allow us to drop Python for most of the project (what would remain are things like make test-v8, which relies on Python, but is only used by a small subset of users and jobs). Our test script could be rewritten in JS and ./configure would be essentially replaced by cmake. Still, that seems like a loooong way from where we are now (and it might not be the direction most of the collaborators want).

[mmarchini]

FWIW, most of the Python issues I've seen lately are coming from our dependencies, and not from our codebase.

[sam-github]

I think #32814 (comment) has broad consensus as "would be great", but it needs work. cmake is in progress, but gyp.js is not.

[sam-github]

Kicked off https://ci.nodejs.org/job/node-test-commit/37549/ against sam-github@b00561d out of curiosity about whether our CI supports python 3 everywhere (I suspect not).

But... it doesn't work because we explicitly call python configure: https://ci.nodejs.org/job/node-test-commit-osx/33473/nodes=osx1015/console

[mscdex]

Honestly if we're going to switch build systems, I'd much rather be it one that is more flexible than gyp, and cmake fits that bill as far as I can tell.

One example is being able to easily detect platform features, something you can't really do with gyp. Having this ability alone would be great for binding authors who currently have to maintain separate "config.h" files for example for each platform, but even then that's not foolproof because installations can still vary in available features/APIs.

Also as cmake is more popular than gyp amongst OSS projects, I think it'd probably make build integration much easier as well for binding authors.

[mmarchini]

@mscdex agreed, but I think it's a harder sell for native modules (although it might be feasible).

[mscdex]

@mmarchini Obviously there would need to be a transition period where both would have to be supported, at least for addons.

[sam-github]

In my comments above, I made the classic mistake of mixing discussion of node itself and addons in the community, sorry.

• core (./configure): broad consensus for using cmake and abandoning gyp files: Strategic initiative to move to cmake for building Node.js? TSC#648
• addons: .gyp files won't be able to be abandoned for a good long time, but gyp.js would at least remove any need for users to have python installed as a build-dependency when building node.js compiled addons

[rvagg]

Re gyp.js, that's been kind of on me and i've been continually dropping the ball on it due to lack of it feeling like a pressing thing. The rough plan was/is something like this:

• get gyp.js and ninja.js transferred into the nodejs org (Fedor agreed to this already)
• ship it in node-gyp behind a --experimental-gypjs flag
• iterate on its compatibility across systems and complexity of gyp config
• (one day) switch to gyp.js as primary builder and keep Python+gyp as a backup for situations it doesn't work
• (eventually) drop Python entirely
• (???) encourage the ecosystem to switch to something more universally supported??? cmake.js is a thing and people are starting to try it out already. But that really just leaves us in a limbo with multiple build systems in the ecosystem. This ship is a lot larger than when the ecosystem had to switch to gyp from waf, it was really just a little nible rivercraft back then.

It's pretty basic as it is now but that's mostly because it hasn't had a reason to be pushed harder, so we need to get it out into the wild and encourage folks to help improve it. Aside from it only supporting very basic gyp configs, Windows support is probably the biggest missing thing right now. But we have plenty of clever folks around that I'm sure would love to help make it work nicely.

[gengjiawen]

drop python2 PRs now are merged.