Make Python 3.7 the minimal required Python version for the worker?

[vdbergh]

These days it is strongly recommended that Python packages are properly type annotated so that static type checkers such as mypy can catch bugs at compile time. However it is virtually impossible to work with type annotations in Python <= 3.6 - even if they are not checked.

For example the crucial from __future__ import annotations which makes it possible to use forward references in type annotations only exists in Python >= 3.7. So I believe it is time to move on, and raise the minimal required Python version in the worker.

[Disservin]

Only a few workers from noob are using 3.6.8 not sure how easy it is to upgrade for him

[vdbergh]

@noobpwnftw Any comments?

[ppigazzini]

https://devguide.python.org/versions/
Status of python versions, 3.8 end of life since October 2024, so if we are dropping the support for 3.6 better to consider the move to 3.9 or higher after asking to the user base affected from the change. With pyenv, conda etc it should be easy to have an up-to-date python on Linux workers. Windows/msys2 workers can be updated easily running the update script.

[vdbergh]

You won't hear any objections from me...

[vdbergh]

We need to be able to contact @noobpwnftw ...

[vdbergh]

What actually triggered this issue is that I enhanced the OpenLock library (the locking library used by the worker) with type annotations. See https://www.cantate.be/openlock for documentation. Sadly OpenLock is now no longer compatible with Python 3.6, so the latest version cannot be used by the current worker.

[peregrineshahin]

We need to be able to contact @noobpwnftw ...

I wonder when will the project grow and become serious enough to the point where it would stop waiting clients to comply instead of begging them to update.

[peregrineshahin]

plot twist there is no hope for that to happen with this re-assuring behavior (on the wrong) that even copy pastes python packages inside our repo.

[vdbergh]

We need to be able to contact @noobpwnftw ...

I wonder when will the project grow and become serious enough to the point where it would stop waiting clients to comply instead of begging them to update.

Well if somebody provides a sizable fraction of the Fishtest resources he cannot be simply called a client IMHO...

[vdbergh]

plot twist there is no hope for that to happen with this re-assuring behavior (on the wrong) that even copy pastes python packages inside our repo.

I don't understand what you are trying to say here...

[peregrineshahin]

There is a simple solution, whoever wants to contribute will not stop contributing just because you want to update the code to better form.
it's a simple equation, about who should fix issues on their part, I don't see the project named as noobtest.
the respect should be mutual.
Whoever contributes to the project even with big resources is not your or my boss.
To this day, changing stuff on your side and forcing the matters hasn't been tried to see if anyone will comply afterwards, even though the OpenBench instances does it with success on getting an interaction.

Are we really grasping at straws just so HW contributors doesn't leave, by harming the project itself?
I don't think that's even how any HW contributor thinks.

[vdbergh]

In principle I agree with you but I believe that it is best to handle such issues in a friendly way - if that's at all possible...

[Disservin]

other instances very much dependent on a few hw contributor's and their engagement with the instance.. it's just that other instances are much more shortlived or setup fairly recently, meaning they don't have any legacy worker versions to care about..

I recently came across xmake (make alternative) and saw that it is able to pull any required toolchain, which could potentially be nice to use for Stockfish, since we can manage the used toolchain without any user interactivity https://xmake.io/#/toolchain/remote_toolchain (just some thoughts)