[08:55:00] !log admin delete 'monitoring' project https://phabricator.wikimedia.org/T365105 [08:55:05] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [09:00:10] !log superpes@tools-bastion-13 tools.stewardbots Restarted StewardBot out of IRC [09:00:12] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stewardbots/SAL [13:40:37] !log superpes@tools-bastion-13 tools.stewardbots Restarted SULWatcher out of IRC [13:40:39] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stewardbots/SAL [20:08:53] !log lucaswerkmeister@tools-bastion-13 tools.wd-image-positions deployed 8f374ee202 (l10n updates: es, zh-hans) [20:08:55] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wd-image-positions/SAL [23:35:27] Hi, I mapped my Toolforge server to use /usr/bin/python3 to handle any request to .py files. When I launch /usr/bin/python3, I'm on 3.11. However, when handling a request, the py file is executed under 3.9. Anyone know why and how to fix that ? [23:37:27] which tool are you working in? [23:37:37] parliamentdiagram-beta [23:38:48] that seems to be running a php7.4 webservice AFAICT [23:38:57] yup [23:39:05] so if there’s any python at all in the container it should be considered an accident, probably [23:39:30] but the lighttpd conf says to handle .py files using /usr/bin/python3 [23:39:34] you could get a python 3.11 with `webservice stop && webservice python3.11 start` [23:39:45] but I see you have plenty of PHP files in your `public_html/` [23:39:45] All my pages are php [23:39:47] this sounds generally like confusion about the differences between the bastions and the containers [23:39:48] so that won’t quite do what you want [23:40:51] It worked quite well as I was using 3.8 compatible syntax, but I need to use more advanced features [23:41:50] Gouvernathor: your webservice runs in a container of some type. To see what is in that container you need to use a shell in the same container type. Running `python3` on a bastion directly is very likely to be a completely different result than running `python3` in your container. [23:42:18] the bastion is where I find myself when I `become` ? [23:42:25] Broadly speaking we do not support multi-language runtimes now that grid engine is gone. [23:42:37] that's a shame [23:43:01] I kinda rely on that [23:43:17] the bastion is what you SSH into, yes (and `become` leaves you on the same host, it’s just a `sudo -u` convenience wrapper) [23:43:28] Gouvernathor: yes, the bastion is the place you ssh to to and run `become`. To enter a container you need to do something like `webservice php8.2 shell` [23:44:23] so when I shell inside my container, I will find the 3.9 python, but I won't be able to change that or upgrade it or whatever [23:44:49] The officially supported multi-language runtime today would be https://wikitech.wikimedia.org/wiki/Help:Toolforge/Build_Service using the Aptfile buildpack [23:46:21] Gouvernathor: you can make some difference by switching to a custom container using the build service. The buildpacks we use don't stack generally though so you would need to pick either PHP or Python as the base and then add the other runtime using Apt [23:46:53] This will not end up being the same thing as tweaking the shared php8.2 container [23:48:27] That seems like a big deal [23:48:31] the Aptfile approach also still limits which Python versions you can select – whatever is packaged in (currently, subject to change) Ubuntu 22.04 (jammy) [23:48:37] which would be Python 3.10, so still an improvement [23:49:00] but AFAICT you couldn’t select, say, Python 3.9 or 3.11 in the Aptfile (unless I’m using packages.ubuntu.com incorrectly) [23:50:01] @lucaswerkmeister: I am pretty sure you are correct. We do not currently allow adding alternate apt repos and the default repos upstream would be single version [23:50:59] depending on the Python program, it *might* be viable to run it as a separate service, in its own container, and have the main webservice talk to it over HTTP [23:51:11] Gouvernathor: you are basically in the situation from https://wikitech.wikimedia.org/wiki/News/Toolforge_Grid_Engine_deprecation#Tools_needing_multiple_language_runtimes [23:51:15] I did that for a while when I hosted a MediaWiki on toolforge, with pygments (syntax highlighting) in a separate container [23:51:27] but that’s pretty involved and also only works for some use cases [23:52:08] So, where would the "image" be created, it would be a file in my bastion ? [23:53:15] Gouvernathor: no, it would be stored in the container registry at tools-harbor.wmcloud.org [23:55:38] would I create it just once, or would it be created anew each time I start the webservice ? [23:56:26] You would need to rebuild it each time you changed the application code inside of it [23:56:59] but once built it will stay in the registry until you over write it with a new build [23:57:17] and the webservice would use the latest image version each time it’s restarted [23:57:32] what do you mean the application code [23:57:41] The whole workflow mostly requires you to move to keeping everything in git. [23:57:54] ok, so each time I push a commit basically [23:57:56] I mean your php, python, images, css, etc [23:57:58] yeah [23:58:18] yeah, I think some tools have a setup to build an image automatically in GitLab CI even [23:58:57] a new build is needed each time you want to see changes in the running app. That might be every commit, or once a day, or once a week or whatever [23:59:42] and the rebuild (and the pull, although I suspect it would be a clone) I need to trigger from the bastion, or from a CI or something