Just something we noticed - this would have been avoided if we had our base image version fixed to a particular release, but anyway just wondering if this (breaking) change was really intentional - we’ve been using
FROM balenalib/%%BALENA_MACHINE_NAME%%-alpine-python:3.6
for a while now, and got some errors in a recent build, until we realised that /usr/bin/python used to point to python 3.6 on that base image, and now points to python 2.7 - we’re now using python3 explicitly throughout the Dockerfile to fix this.
Just a bit more information based on some checks I ran:
when I launch a fresh container with
balena run -it --entrypoint=/bin/bash balenalib/fincm3-alpine-python:3.6
it seems that I am getting an Alpine 3.6, with python 2.7 - which would go against the tag specification in https://www.balena.io/docs/reference/base-images/base-images/ - according to which language version is the first element of the tag, and I would assume the following components (including the distro version) to default to latest
so it seems that for the single-version-number alpine-python base image, the version tag is incorrectly treated as the version of the operating system rather than the version of Python. It’s not the case for Node by the way, so it seems like an isolated case with that particular image?
Hey @maciej-ldc, thank you very much for the report, the combination of Python 2.7 with Alpine Linux 3.6 and Python 3.6 with any Alpine Linux release are both valid for the image balenalib/%%BALENA_MACHINE_NAME%%-alpine-python:3.6 with the tag specification in our docs since as we mention in the docs, In the tags, all of the fields are optional and if they are left out, they will default to their latest pointer. (https://www.balena.io/docs/reference/base-images/base-images/#image-tags)
I will discuss with our team to clarify what version should be used for these edge cases.
Hi @nghiant, thanks for the reply - I think taking Alpine 3.6 rather than Python 3.6 in this example is incorrect according to the examples in the balena documentation, see here: https://www.balena.io/docs/reference/base-images/base-images/#examples (a Node example) - where only one version is provided and it’s treated as the language version - which is indeed the behaviour for Node-based containers, as shown in my tests above.
in the Node-based images, Node versions don’t conflict with with Distro version so we won’t have this problem, In case of Alpine Linux with Python, 3.6 can be understood as Alpine Linux release or Python version which is the problem here. We will need to discuss with the team regarding this matter and will get back to you soon.
Of course, I understand the need to discuss this in the team. Thank you for following up quickly on the issue.
If I may throw in my two cents from the user’s point of view - I don’t think it should matter whether for a particular language stack and distribution there’s a clash between version numbering or not. The specification says the language version goes first, and distribution version goes second. If there’s only one version provided, then it seems quite intuitive for it to be treated as the language version - just like in most programming languages, if you pass only one parameter to a function, it is treated as the first parameter and the other parameters will be assigned their default values. Trying to determine a non-standard order of assigning values to parameters is IMHO dangerous because it’s less predictable.
Also please note that this used to be consistent across at least node and python until sometime in the last month when a breaking change got released.