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
Python is outdated even in the :XX versions (no tags) #1528
Since NPM and also PNPM, which already did this, are looking forward to update to the latest node-gyp there is a major problem with the official docker containers. Those deliver an outdated python (3.5, needed is 3.6), this will generate tons of problems (it did already for us...) for users, especially since this will be an interrupting change for all those that use i.e. node:14, so one of the docker versions that have the build tools and have no further tags, like alpine or others.
Those docker versions and also the others should deliver a python that is not unmaintained (that seems to be the major reason for node-gyp to drop python 3.5. b/c it is not maintained any more), otherwise this will be a major disruption for all users as soon as NPM goes and updates.
no reason to ignore and close this immediately @nschonni . If you would have cared for the impact this will have then you would ackknowledge the upcoming problem see nodejs/node-gyp#2392 .
But good to know that integrity with the official node tooling is not important to the maintenance of the docker image. I will form an announcement internally to ban the official node image.
The latest tag is an alternative name to 16.6.0-buster, and being based on Debian Buster has Python 3.7 available. But there are many tags here based on Debian Stretch and those are the ones that only have Python 3.5 available. There are -buster tags for every supported version of node, like 14.17.4-buster. But on versions less than 16 the plain tags (like 14 and 14.*) were left on stretch so that it was less likely to break users with an sudden OS upgrade when Buster versions were added.
TLDR; use 14-buster to get a Debian Buster based image with node 14 (same for 12-buster).
@wzrdtales I will reiterate what @yosifkit said, the primary goal is to prevent breaking people's build by changing environment on them so the shorthanded tag remain pinned to the version of debian that was supported at the time the docker image became available. The shorthanded tag are a convenience but I would almost always recommend to be more specific with tags like 14.17.4-buster as mentioned before.
Activity
nschonni commentedon Jul 28, 2021
The image doesn't ship any version of Python. It adds it as part of the build when needed, then removes those dependencies after.
What ever out dated version may be in the image is part of the base, and not something we touch.
Alpine users have to add their own for any native builds https://github.com/nodejs/docker-node/blob/main/docs/BestPractices.md#node-gyp-alpine
wzrdtales commentedon Jul 28, 2021
no reason to ignore and close this immediately @nschonni . If you would have cared for the impact this will have then you would ackknowledge the upcoming problem see nodejs/node-gyp#2392 .
But good to know that integrity with the official node tooling is not important to the maintenance of the docker image. I will form an announcement internally to ban the official node image.
yosifkit commentedon Jul 30, 2021
The
latesttag is an alternative name to16.6.0-buster, and being based on Debian Buster has Python 3.7 available. But there are many tags here based on Debian Stretch and those are the ones that only have Python 3.5 available. There are-bustertags for every supported version of node, like14.17.4-buster. But on versions less than16the plain tags (like14and14.*) were left on stretch so that it was less likely to break users with an sudden OS upgrade when Buster versions were added.TLDR; use
14-busterto get a Debian Buster based image with node14(same for12-buster).Debian Stretch based images will definitely be dropped sometime next year when the OS reaches end of LTS (https://wiki.debian.org/DebianReleases).
LaurentGoderre commentedon Aug 11, 2021
@wzrdtales I will reiterate what @yosifkit said, the primary goal is to prevent breaking people's build by changing environment on them so the shorthanded tag remain pinned to the version of debian that was supported at the time the docker image became available. The shorthanded tag are a convenience but I would almost always recommend to be more specific with tags like
14.17.4-busteras mentioned before.