The python image is based on Jessie which includes an almost EOL'ed version of Python.
We should use the Stretch base image.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
The python35 image is based on Stretch, so we should decide what do to for the default python image. Is the policy to create new versioned images and let python get deprecated?
Comment Actions
Additionally, as pointed by @Danmichaelo, python35 is missing from webservice:
$ webservice --help usage: webservice [-h] [--backend {gridengine,kubernetes}] [type] {start,stop,status,restart,shell} [extra_args] Online documentation: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web Supported webservice types: Kubernetes backend: golang, jdk8, nodejs, php5.6 (default), php7.2, python, python2, ruby2, tcl Grid Engine backend: generic, lighttpd (default), lighttpd-plain, nodejs, tomcat, uwsgi-plain, uwsgi-python
I think this might be a WIP task, CC @bd808
Comment Actions
As pointed out by @Chicocvenancio, this was also mentioned in http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-cloud/20190322.txt :
[18:01:56] <bd.808> pin.toch: we have a python3.5 Kuberentes container built, but it is not exposed for use yet. I expect to make it available in the first week of April
Comment Actions
Python 3.4 is now no longer supported by upstream; one consequence is that mypy has dropped support for it, making my CI build for a tool fail. Until this task is resolved, I believe the only options I have are to not run mypy in CI anymore, or to run CI against a different version of Python than the one that will ultimately be used on Toolforge. I don’t really like either option, so I hope this task will be resolved soon :)
Comment Actions
It seems mypy is installed through pip, so another option could be to pin the mypy version to one that still supports 3.4.
Comment Actions
This is especially confusing given that python3 --version returns 3.5.3 when logging in to tool forge and becomeing the tool user.
Having seen that, I happily dropped django 2.0 which was EOL'd in April (and was the last version to support python 3.4) in my tool, assuming that python on toolforge has been upgraded to 3.5.
Please, make python 3.5 available. Running on EOL'd stack is no fun (especially if you are a volunteer with a regular job).
Comment Actions
$ webservice --backend=kubernetes python3.5 shell Defaulting container name to interactive. Use 'kubectl describe pod/interactive -n bd808-test' to see all of the containers in this pod. If you don't see a command prompt, try pressing enter. $ python3 --version Python 3.5.3 $ logout Session ended, resume using 'kubectl attach interactive -c interactive -i -t' command when the pod is running Pod stopped. Session cannot be resumed.