-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Python version 3.12 and 3.13 #1465
Support for Python version 3.12 and 3.13 #1465
Conversation
… for testing Local Windows build set to Python 3.12 for further testing
For now this PR is work in progress. |
Thank you for such a detailed PR. Let me know when it's ready for review/merge. |
…karound for regression in actual pefile 2024.8.26
…3, 14 and 15 for testing. Add python Python 3.11, 3.12 and 3.13 for testing
Hi @rockstorm101, Some good news. It looks like we can run Pronterface with Python 3.13 w/o the experimental free-threaded mode as well. 🙂 Plyglet 1.5 became an update some days ago to version 1.5.30 (pyglet/pyglet#1243) which make the 3D visualization working for Python 3.13 again. Test with Windows 10:
Latest Windows Artifacts: https://github.com/kliment/Printrun/actions/runs/12306812910 Additional changes for Windows: MacOs: Build-wheels: After testing we need to decide what versions we want to remain for all workflows. |
Hello @DivingDuck,
The modern macOS is a different story:
![]()
![]()
That means we will have to improve the instructions on how to install and open Pronterface on mac. |
@neofelis2X,
1 Tested with Macbook |
Okay, so that would be the table from my side. Which versions / combinations do you want to release? I also started to write a little manual on how to handle the security warnings. Footnotes |
Hi @neofelis2X, Sorry for my late answer. A flue catch me last week. Python 3.13 because of Pythons fast development cycle and it seems to be fine for all macOS versions so far. What do you think about this choice? Great that you are already start writing a little manual for the installation. +1 I was thinking about Python for the Windows in the same direction - one version with actual version and maybe one with an older version. All other combinations can be build locally from a user as I provide this in the local build script as already shown above. @rockstorm101, |
For pre-built binaries that are distributed to users I would aim for the lowest version of OS plus the lowest version of Python possible. Because that binary will work (correct me if I'm wrong here) on every OS version above that. Essentially I'm trying to make things simple for users. If one binary works for everyone, just give them one binary and users won't have to decide which binary they have to download. If not, let's try to reduce the number of binaries to the very minimum.
The current recommended way of installing on Linux is via PyPI and there we upload every possible combination so I don't see a debate there. If we fix the pyglet issue, then linux distro packages will create their packages for whatever versions work for them, again, no need for us (upstream) to worry about it I think. So, all good from Linux point of view. |
No problem, I was also quite occupied these days. I wish you a speedy recovery then!
I generally agree with that, one binary would probably work well for everyone.
How should I upload it? A separate PR that changes the README? Or as a new file, that we can also include into the released .zip file? |
Sounds good to me. Maybe not all macOS 14 users have Python 3.13? Or does it come by default with that Python version?
I'm happy either way. I'd say aim for the README if it is short. Otherwise, a separate file could do. @DivingDuck did some work on GitHub's Wiki pages which could also be an option. |
Hi, sorry for the long silence. I got a bit distracted.
Python is packaged within the macos application. So it doesnt need to be installed. :)
Yes, I checked out the wiki and found it to be a good place for this instructions. But now I can not upload my changes because I have no access rights. And wikis don't support regular PRs, it seems? Can I get rights to upload to the wiki? |
Hi, Reminder to myself: |
Regarding Python, I want to settle this
I don't know. On the other side Py3.13 is the actual standard version since Oct. 2024 and as mentioned it have some benefits for the actual macOS. I have the same situation for Window and Visual Studio 2022. Python 3.13 is not official supported but compile correct and Visual Studio Code do support that version. However when I look to Python 3.8, Visual studio compile the x64 but not x86 locally and with Github I can compile both version flawlessly with the build in VS 2022. Anyway, here is my suggestion: MacOS: Windows: Linux: |
You should have them know. Thanks for contributing! :)
Sounds good to me. Let's go with that.
We can definitely ditch Python 3.8 since it is no longer supported anyway. However I would do as you suggested and keep support for the lowest Python version possible to help people with old hardware. Nonetheless, if packaging effort becomes a burden, we must of course optimize our little spare time and maybe just support the latest stable Python. So up to you really. |
Thank you very much! Wiki is updated and #1479 is pushed. |
…es for Windows x86/x64 with Python 3.8 and 3.13, Build packages for macOS-13 and -14 with Python 3.11 and 3.13
Short answer: if it is simple to add, I would add it. Long answer: In the old days, the norm was that binary distributed packages should be "self-contained". Meaning that a user that got such package should not require internet or any other resource to make use of the software. Which means the documentation had to be packaged with the software so the user could understand and use it. In the modern days where everyone's got a phone with internet access I believe such norm could be relaxed really. But... old habits die hard ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for enhancing the documentation!
…ement in hierarchy
… DE is 100% complete
@rockstorm101, New updates:
Latest artifacts: Let me know what you think and if there is missing something. Remark regarding Python: With Python 3.12 the organization stop shipping the Tools collection. Part of the tool collection was the tool set of I16N, what included the tool for generating the translation file pronterface.pot (with pygettext.py) and creating the binary *.mo files (with msgfmt.py) as build in python solution at least for Windows. |
Really looking forward for this to be merged, to get rid of the syntax warnings. :) I will test the artefacts on the weekend and look through. the texts. |
The artifacts work well and I dont have additional comments on the changes. 👌 But I am confused about the translation. I tried to get Printrun to run in German, compiled the .po into a .mo with Poedit and tried different locations for the locals folder. But no success, it always stays English. Are the translations expected to work already? |
Hi @neofelis2X,
Three things worth to check:
Edit after taking a look in the code:
So maybe something like Edit: |
Thank you for the hints, that helped a lot to pin down the problem. The translations do work, but printrun is looking for them at the wrong location, in this case. macOS has a folder Usually the localisation files are in the Resources folder of the Application-bundle. As a quick fix this lines: if osPlatform == "Darwin":
# improvised workaround for macOS crash with gettext.translation, see issue #1154
if os.path.exists(shared_locale_dir):
gettext.install(domain, shared_locale_dir)
else:
gettext.install(domain, './locale') could be changed like this: if osPlatform == "Darwin":
# improvised workaround for macOS crash with gettext.translation, see issue #1154
gettext.install(domain, './locale') Then it would work just the same as it does for windows now. |
Thanks a lot for testing. I like your solution and will change the code. This makes the handling with translations more simple. |
…e binary file is located (same as for Windows)
New updates:
Latest artifacts: For me the PR is now ready to merge if there are no further findings. Please check the latest changes. Thank you very much for your help @rockstorm101 & @neofelis2X |
Thanks for your efforts here. Unless @neofelis2X wants to add anything I'm happy to merge now. |
Nope, i have nothing to add, looks great! |
Thanks for your work on this one @DivingDuck. I would simply suggest to maybe split the work into several simpler/shorter PRs for the future, one for each topic (e.g. syntax fix, CI stuff, translations,...). I feel like it keeps things tidier and more modular and does not tie one thing to the other. It also makes reviews simpler. If one big PR works better for you though, keep it like that. This is just a suggestion. |
@rockstorm101, I try to do so next time. 😇 |
Build with 3.13 is still experimental. It builds the binaries but due to compiling errors in library pyglet version 1.5.29 we miss the support for 3D visualization. Beside this Pronterface and Pronsole is fully functional.
Changes in release_windows.bat
Python 3.13 is still experimental as there is for now no 3D visualization available because of incompatibility issues with pyglet
CleanCacheFiles.bat
This batch file will clean up all pycache folders, *.pyd files and left over gcoder_line files from previous builds. For local Windows only. It is helpful when you switch between Python versions or you have problems with incompatible library files or versions.
Changes in requirements.txt
Remove dedicated version for pillow in Windows build environment
pillow < 10.0; sys_platform == 'win32'
--> to:
pillow ;sys_platform == 'win32'
Changes in buildpackage-win.yml
Add support for Python 3.12 and 3.13 and mark Python 3.13 as experimental
Various fixes for visible SyntaxError warnings of invalid escape sequence when compiling with Python 3.12 and 3.13
(in question to become in Python >3.13 a syntax error)
See https://docs.python.org/dev/whatsnew/3.6.html#deprecated-python-behavior:
A backslash-character pair that is not a valid escape sequence now generates a DeprecationWarning.
Although this will eventually become a SyntaxError, that will not be for several Python releases.
(Contributed by Emanuel Barry in bpo-27364.)
and https://docs.python.org/3/reference/lexical_analysis.html, Chapter 2.4.1.1. Escape sequences:
Changed in version 3.6: Unrecognized escape sequences produce a DeprecationWarning.
Changed in version 3.12: Unrecognized escape sequences produce a SyntaxWarning. In a future Python version they will be eventually a SyntaxError.
Solution: Change string to raw string when escape sequences are involved
\printrun\pronterface.py:2099: SyntaxWarning: invalid escape sequence '\d'
self.sdfiles.append(re.sub(" \d+$", "", line.strip().lower())) # NOQA
--> to:
self.sdfiles.append(re.sub(r" \d+$", "", line.strip().lower())) # NOQA
\printrun\pronsole.py:61: SyntaxWarning: invalid escape sequence '\d'
tempreading_exp = re.compile('\\bT\d*:')
--> to:
tempreading_exp = re.compile(r'\\bT\d*:')
\printrun\pronsole.py:201: SyntaxWarning: invalid escape sequence '\d'
self.lineignorepattern=re.compile("ok ?\d*$|.*busy: ?processing|.*busy: ?heating|.*Active Extruder: ?\d*$")
--> to:
self.lineignorepattern = re.compile(r"ok ?\d*$|.*busy: ?processing|.*busy: ?heating|.*Active Extruder: ?\d*$")
\printrun\pronsole.py:1140: SyntaxWarning: invalid escape sequence '\d'
self.sdfiles.append(re.sub(" \d+$","",line.strip().lower()))
--> to:
self.sdfiles.append(re.sub(r" \d+$","",line.strip().lower()))
\printrun\gcoder.py:28: SyntaxWarning: invalid escape sequence '('
gcode_exp = re.compile("\([^\(\)]*\)|;.*|[/\*].*\n|([%s])\s*([-+]?[0-9]*\.?[0-9]*)" % to_parse)
--> to:
gcode_exp = re.compile(r"\([^\(\)]*\)|;.*|[/\*].*\n|([%s])\s*([-+]?[0-9]*\.?[0-9]*)" % to_parse)
\printrun\gcoder.py:29: SyntaxWarning: invalid escape sequence '('
gcode_strip_comment_exp = re.compile("\([^\(\)]*\)|;.*|[/\*].*\n")
--> to:
gcode_strip_comment_exp = re.compile(r"\([^\(\)]*\)|;.*|[/\*].*\n")
\printrun\gcoder.py:30: SyntaxWarning: invalid escape sequence '('
m114_exp = re.compile("\([^\(\)]*\)|[/\*].*\n|([XYZ]):?([-+]?[0-9]*\.?[0-9]*)")
--> to:
m114_exp = re.compile(r"\([^\(\)]*\)|[/\*].*\n|([XYZ]):?([-+]?[0-9]*\.?[0-9]*)")
\printrun\gcoder.py:31: SyntaxWarning: invalid escape sequence '('
specific_exp = "(?:\([^\(\)]*\))|(?:;.*)|(?:[/\*].*\n)|(%s[-+]?[0-9]*\.?[0-9]*)"
--> to:
specific_exp = "(?:\([^\(\)]*\))|(?:;.*)|(?:[/\*].*\n)|(%s[-+]?[0-9]*\.?[0-9]*)"
\printrun\device.py:209: SyntaxWarning: invalid escape sequence '.'
host_regexp = re.compile("^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$|^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\-]*[A-Za-z0-9])$")
--> to:
host_regexp = re.compile("^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$|^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\-]*[A-Za-z0-9])$")
\printrun\gcodeplater.py:48: SyntaxWarning: invalid escape sequence '.'
rewrite_exp = re.compile("(%s)" % "|".join(["X([-+]?[0-9]*\.?[0-9]*)",
--> to:
rewrite_exp = re.compile("(%s)" % "|".join([r"X([-+]?[0-9]*\.?[0-9]*)",
\printrun\gcodeplater.py:49: SyntaxWarning: invalid escape sequence '.'
"Y([-+]?[0-9]*\.?[0-9]*)"]))
--> to:
r"Y([-+]?[0-9]*\.?[0-9]*)"]))
Can't be fixed because external library and do not harm:
\v3\Lib\site-packages\pyglet\gl\wgl.py:36: SyntaxWarning: invalid escape sequence '\c'
"""Wrapper for C:\cygwin\home\Alex\pyglet\tools\wgl.h