feat: python 3.12 support

[Laikulo]

Entirely just some adjustments to dependencies.
Based on initial analysis by Sineos over at the discourse: https://klipper.discourse.group/t/discuss-python-versions/20942/10

[Laikulo]

Import test succeeds, runs on a multi-mcu test box with kinematics: None

[Laikulo]

Regression tests pass on py3.12, with fresh dicts built on buster.
py_3_12_tests.txt

[nefelim4ag]

BTW:

$ ~/klippy-env/bin/python3 -m pip list | grep setup
setuptools         75.1.0
$ ~/klippy-env/bin/python3 -m pip list | grep python-can
python-can         3.3.4
$ ~/klippy-env/bin/python3 --version
Python 3.12.6

But of course, the correct versions are better,
If there are green light on 3.12, I can reinstall Klipper with those if it helps with testing and even migrate back to USB-CAN to cover python-can.

[KevinOConnor]

Thanks for looking at this. In general it seems fine. I'd just like to confirm that we do need to pin these versions and that there isn't some version of setuptools and python-can that works with a wide variety of python versions?

Cheers,
-Kevin

[Laikulo]

Setuptools isn't needed at all on older versions, it provides a backfill for distutils, which has been removed.
python-can after 4.x doesn't support py2.x, and 3.x doesn't appear to work on py3.12. It might be possible to give a wider selector, I did strict equality, as that is how all the others were specified.

[KevinOConnor]

Okay, thanks. So we have to specify two different versions for python-can (one for <3.12 and one for >3.12). I didn't understand your answer about setuptools though - there is not a version of setuptools we can reasonably use across all python versions? (It's fine if the answer is yes - I just want to be sure I understand the change.)

Cheers,
-Kevin

[Laikulo]

It's more that we don't need setuptools in prior versions, because the functionality that it is adding was part of the standard distribution.

https://peps.python.org/pep-0632/

Setuptools contains compatibility shims that allows the use of the distutils package and modules.

[KevinOConnor]

I think it'd be preferable to have every instance be pinned to a single version of setuptools, even if not all instances need it. It's just easier for debugging and troubleshooting if all instances are running as much of the same code as possible.

I understand if we can't pin a single version though - so that's my main question - do you know if we can pin a single version of setuptools?

Thanks again,
-Kevin

[flowerysong]

AFAIK the requirement is either to upgrade python-can or to install setuptools (which old versions of python-can rely on for reasons unrelated to distutils.) Both should not be necessary.

[github-actions]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
   If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[KevinOConnor]

My local desktop runs fedora with python v3.12.8 . Even with the current klippy-requirements.txt, I'm not having any issues installing the Klipper virtualenv and running Klipper (at least enough to run the regression test cases). So, at least on Fedora, it doesn't seem we need any changes for python 3.12 . Can someone provide more details on how and where Klipper is failing with python3.12?

-Kevin

[flowerysong]

As I previously linked: #6550

[KevinOConnor]

Okay thanks. I can reproduce the failure if I run an explicit import can on python 3.12. I went ahead with the simple change of pinning setuptools when on python v3.12 (commit 01b0e98).

-Kevin

EDIT: Also, there is also no single version of setuptools that works on all versions of python we support. (Quite the mess.) So, pinning setuptools only on python 3.12 seems to be the simplest fix for now.