Are there systems where python3 exists and python3.10 doesn't? If there are and webui works on them, this change will make webui stop working.

Just edit webui.sh:
uncomment #python_cmd="python3" (this line is commented so there's no need to change it in original repo);
and then you can define python_cmd="python3.10" yourself.
This is all you need, and there is no need to PR.

Are there systems where python3 exists and python3.10 doesn't? If there are and webui works on them, this change will make webui stop working.

Users who has only one Python version other than 3.10, will have python3, but not python3.10 available. For example:

❯ python3 --version
Python 3.8.10

❯ python3.10 --version
zsh: command not found: python3.10

Also, if you merge this PR, it would make this check completely useless.

Are there systems where python3 exists and python3.10 doesn't? If there are and webui works on them, this change will make webui stop working.

Users who has only one Python version other than 3.10, will have python3, but not python3.10 available. For example:

❯ python3 --version
Python 3.8.10

❯ python3.10 --version
zsh: command not found: python3.10

Also, if you merge this PR, it would make this check completely useless.

for those users, they can install python3.10 seperately, for example, apt install python3.10;
then just edit webui.user.sh like I mentioned above.

for those users, they can install python3.10 seperately, for example, apt install python3.10; then just edit webui.user.sh like I mentioned above.

You are missing the point. We were talking about users with working installations who has some other python version (not 3.10). I know that some people use 3.11 on Linux and they do not have 3.10 installed. This PR would break everything for them and they will have to do what you are suggesting.

for those users, they can install python3.10 seperately, for example, apt install python3.10; then just edit webui.user.sh like I mentioned above.

You are missing the point. We were talking about users with working installations who has some other python version (not 3.10). I know that some people use 3.11 on Linux and they do not have 3.10 installed. This PR would break everything for them and they will have to do what you are suggesting.

Breaking out of spec setups is unfortunate, but the project clearly expects you to run it with python3.10 and merging this change would be helpful in making sure its not trying to run on an unsupported version of python, your everyday user should not need to tinker with files to tell it to pick the python version its expecting.

Breaking out of spec setups is unfortunate, but the project clearly expects you to run it with python3.10 and merging this change would be helpful in making sure its not trying to run on an unsupported version of python, your everyday user should not need to tinker with files to tell it to pick the python version its expecting.

Since I am not a part of the dev team, I can only give my opinion, but devs will decide whether they will accept this PR or not.

I agree that 3.10 is the recommended version, and everyone should use that version if possible, but as you can see in
#15716 some people need 3.12. I also saw that some other people need to use older versions.

I think that we need a better approach that will try to use 3.10 if possible, but if not, fall back to any other version. If your solution worked that way, I would upvote it immediately.

EDIT:
I just created a PR with a fallback, that solves the mentioned problems and does not break anything

Merged #16092 in.