Skip to content
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

Merged
merged 30 commits into from
Feb 20, 2025

Conversation

DivingDuck
Copy link
Collaborator

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

  1. Change pyglet==1.5.27 to pyglet==1.5.29
  2. Add Python 3.12 and 3.13 as build option, remove support for Python 3.7
    Python 3.13 is still experimental as there is for now no 3D visualization available because of incompatibility issues with pyglet
  3. Add library pytest to additional libraries
  4. Add removal of gcoder_line.cp???-win_amd??.pyd files with python versions that have 3 instead of 2 digits
  5. Remove folder \build in addition as it will not removed any longer automatically in the build process
  6. Remove manual fix for pillow==9.5 as no longer needed

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

@DivingDuck
Copy link
Collaborator Author

For now this PR is work in progress.

@rockstorm101
Copy link
Collaborator

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.

@DivingDuck
Copy link
Collaborator Author

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.
I did some tests for all supported python versions from 3.8 up to 3.13 in x32 and x64 with the new version of pyglet to be sure we don't come in trouble.

Test with Windows 10:

Py version x86 x64
3.13.1t no no
3.13.1 ok ok
3.12.8 ok ok
3.11.9 ok ok
3.10.11 ok ok
3.9.13 ok ok
3.8.10 no ok

Latest Windows Artifacts: https://github.com/kliment/Printrun/actions/runs/12306812910

Additional changes for Windows:
release_windows.bat and windows workflow: Remove remark for experimental support for Python 3.13 and add that the experimental Python 3.13t is not supported for now.
release_windows.bat: remove library pypiwin32 and add pywin32 as this version seems to be more supported and compatible with all our supported Python versions for windows. https://pypi.org/project/pywin32/ , https://pypi.org/project/pypiwin32/

MacOs:
macos-12 is now no longer supported. See issue #1461. I removed macos-12 from the macOS workflow and add macos-13, macos-14 and macos-15 for testing.
In addition I remove Python 3.10 as this version isn't compatible with macos-14 and newer. Therefore I add Python 3.11, 3.12 and 3.13 for testing.
Observation from the logs: The workflow step of Build Cython ext contains some warnings.
I can't test those versions as I haven't a Mac available.
Latest macOS Artifacts: https://github.com/kliment/Printrun/actions/runs/12306812915

Build-wheels:
I changed this workflow as well for macOS. Removed macos-12 and add macos-13
Latest build-wheels Artifacts: https://github.com/kliment/Printrun/actions/runs/12306812905
Test needed for Linux as well. Is there something to do in addition for the Linux part?

After testing we need to decide what versions we want to remain for all workflows.

@neofelis2X
Copy link
Collaborator

Hello @DivingDuck,
thank you for updating the builds. I tested some of the artifacts on a macOS 15.1.1 and on a macOS 12.7.6

  • Surprisingly, the macos-13 artifacts run on my old macos12 macbook. The later builds do not. That is expected.

The modern macOS is a different story:

  • All artifacts work on macos 15. But macos really does not want to open them.
  • First I get this message and with no option to open them at all:
Screenshot 2024-12-13 at 14 18 44
  • Then I had to dig in the settings to find this option. There was no hint anywhere that I have this option as a user.
Screenshot 2024-12-13 at 14 13 13
  • After clicking on 'Open Anyway' it just works.

That means we will have to improve the instructions on how to install and open Pronterface on mac.

@DivingDuck
Copy link
Collaborator Author

@neofelis2X,
thank you very much taking the time for testing. Indeed, we need to improve the documentation for macOS then.
Guess we should build in addition a matrix of what platform, macOS- and python version works and what not. Something like this if it makes sense:

Platform Python x64 macOS 12.7.6 1 macOS 15.1.1
macos-13 py 3.10 ok ok no
macos-13 py 3.11 ok ok no
macos-13 py 3.12 ok ok no
macos-13 py 3.13 ok ok no
macos-14 py 3.10 no no ?
macos-14 py 3.11 ok no ?
macos-14 py 3.12 ok no ?
macos-14 py 3.13 ok no ?
macos-15 py 3.10 no no no
macos-15 py 3.11 ok no ok
macos-15 py 3.12 ok no ok
macos-15 py 3.13 ok no ok

1 Tested with Macbook

@neofelis2X
Copy link
Collaborator

Platform Python x64 macOS 12.7.6 1 macOS 15.1.12
macos-13 py 3.10 ok untested untested
macos-13 py 3.11 ok yes yes
macos-13 py 3.12 ok yes yes
macos-13 py 3.13 ok yes yes
macos-14 py 3.10 no no no
macos-14 py 3.11 ok no yes
macos-14 py 3.12 ok no yes
macos-14 py 3.13 ok no yes
macos-15 py 3.10 no no no
macos-15 py 3.11 ok no yes
macos-15 py 3.12 ok no yes
macos-15 py 3.13 ok no yes

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

  1. Tested on a 2015 Intel Macbook

  2. Tested on a 2022 M2 Macbook

@DivingDuck
Copy link
Collaborator Author

Hi @neofelis2X,

Sorry for my late answer. A flue catch me last week.
Regarding combinations I think we should provide two versions to have a brighter basis for macOS users. MacOS-13 with actual Python 3.13 and macOS-15 with Python 3.13.

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,
Any suggestions from your side, especially for Linux platforms?

@rockstorm101
Copy link
Collaborator

Regarding combinations I think we should provide two versions to have a brighter basis for macOS users. MacOS-13 with actual Python 3.13 and macOS-15 with Python 3.13.

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.

Any suggestions from your side, especially for Linux platforms?

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.

@neofelis2X
Copy link
Collaborator

No problem, I was also quite occupied these days. I wish you a speedy recovery then!

I would aim for the lowest version of OS plus the lowest version of Python possible. [...] Essentially I'm trying to make things simple for users.

I generally agree with that, one binary would probably work well for everyone.
However, I did some tests with the versions and compared macos13-python3.11 with macos14-python3.13 : The newer version has a 40% smaller filesize, starts almost 50% faster and also seems to open files about 20% - 30% faster. That are some pretty nice benefits.
On that basis I propose to combine both of your suggestions and release macos13-python3.11 for older macs and macos14-python3.13 for modern macs.

Great that you are already start writing a little manual for the installation. +1

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?

@rockstorm101
Copy link
Collaborator

I propose to [...] release macos13-python3.11 for older macs and macos14-python3.13 for modern macs.

Sounds good to me. Maybe not all macOS 14 users have Python 3.13? Or does it come by default with that Python version?

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?

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.

@neofelis2X
Copy link
Collaborator

Hi, sorry for the long silence. I got a bit distracted.

Or does it come by default with that Python version?

Python is packaged within the macos application. So it doesnt need to be installed. :)

GitHub's Wiki pages which could also be an option.

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?

@DivingDuck
Copy link
Collaborator Author

Hi,
Sorry for my late answer. I enjoyed a 3 weeks break w/o looking to any kind of emails - what a pleasure.
Now I'm able to go (slowly) to all the open ends and emails.

Reminder to myself:
Don't forget to update translation files (#1473 (comment)) before this PR will be implemented

@DivingDuck
Copy link
Collaborator Author

Regarding Python, I want to settle this

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 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:
macos13-python3.11 for older macs and macos14-python3.13

Windows:
Python 3.8 as this is now really the last time for x86/x64 (as last chance for really old Windows machines) and Python 3.13 for Windows 10 and 11
Remark: I want to get rid of all EOL Python versions for Windows as soon as possible. Ideally we should support 3.12 as min Version for the future. Who want to use older versions should build and test them locally.

Linux:
What ever is supported via pypi

@rockstorm101
Copy link
Collaborator

Can I get rights to upload to the wiki?

You should have them know. Thanks for contributing! :)

here is my suggestion:

MacOS: macos13-python3.11 for older macs and macos14-python3.13

Windows: Python 3.8 as this is now really the last time for x86/x64 (as last chance for really old Windows machines) and Python 3.13 for Windows 10 and 11 Remark: I want to get rid of all EOL Python versions for Windows as soon as possible. [...]

Linux: What ever is supported via pypi

Sounds good to me. Let's go with that.

Ideally we should support 3.12 as min Version for the future. Who want to use older versions should build and test them locally.

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.

@neofelis2X
Copy link
Collaborator

You should have them know. Thanks for contributing! :)

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
@rockstorm101
Copy link
Collaborator

about adding the file readme.md to the binary distribution packages. Do you think we should still do this?

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 ;)

Copy link
Collaborator

@rockstorm101 rockstorm101 left a 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!

@DivingDuck
Copy link
Collaborator Author

DivingDuck commented Feb 14, 2025

@rockstorm101,
thanks a lot for your input, I change all points you mentioned.

New updates:

  • Merge latest changes from master branch
  • README.md:
    • Fix all typos as mentioned
    • Put the chapter Translating Pronterface in hierarchy one up
    • extend chapter translating a little bit
    • add new chapter Important: Allow the application to run on Windows,
      I shamelessly copy the existing part from macOS and link to the related FAQ section of the wiki
  • Add README.md to the binary distribution package of Windows and macOS
  • pronsole.py:
    • Fix two not translatable f-strings
      Background is that pygettext.py can't handle f-strings and do ignore those strings with an error. The solution was a not so elegant translation string construct, but it works.
  • Update all translation files because of code changes. Translation for DE is 100% complete

Latest artifacts:
Windows: https://github.com/kliment/Printrun/actions/runs/13332800561
MacOS: https://github.com/kliment/Printrun/actions/runs/13332800555
Wheels: https://github.com/kliment/Printrun/actions/runs/13332800550

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.
My solution is for now using the latest pygettext.py version of py 3.11 for this task and updating the *.po files / building the *.mo files with Poedit locally. Not elegant, but it is as it is. I'm quite happy that this is not automated with github actions up to now. It solves me some head-edge for now ...

@neofelis2X
Copy link
Collaborator

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.

@rockstorm101 rockstorm101 linked an issue Feb 16, 2025 that may be closed by this pull request
@neofelis2X
Copy link
Collaborator

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?
And what would be my steps to use them?

@DivingDuck
Copy link
Collaborator Author

DivingDuck commented Feb 16, 2025

Hi @neofelis2X,
on Windows I copy the folder locale to the folder where the binaries of Pronterface are stored and Pronterface then find the needed .mo file based on the system language of your system in the locale folder.

.\Pronterface
   .\locale
     .\de
       .\LC_MESSAGES
         pronterface.po
         pronterface.mo
     .\it
       .\LC_MESSAGES
         pronterface.po
         pronterface.mo
     ...
    pronterface.pot
   Pronterface.exe
   Pronsole.exe
   Plater.exe

Three things worth to check:

  • What happen if you run Pronterface from source with a copy of the .mo file in the locale folder?
  • Copy the .mo file in the directory that represent your language in case your system language is different to the language file you want to test ( e.g. your system language is English: create a folder structure for .\en and copy the folder .\LC_MESSAGES from .\de into .en\
  • If I remember correct Linux and macOS save translations on a different place, was it a shared folder?

Edit after taking a look in the code:
Take a look on .\printrun\utils.py line 41 ff and there at line 47:

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')
else:
    if os.path.exists('./locale'):
        translation = gettext.translation(domain, './locale',
                                          languages=[lang[0]], fallback= True)
    else:
        translation = gettext.translation(domain, shared_locale_dir,
                                          languages=[lang[0]], fallback= True)
    translation.install()

So maybe something like usr/share/locale ? Link to issue #1154

Edit:
In the end a good point. Guess we need to extend the documentation for this regard...

@neofelis2X
Copy link
Collaborator

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 /usr/share/locale/ but for regular users is it read-only and I can't just copy files there.

Usually the localisation files are in the Resources folder of the Application-bundle.

Open to see example

The Resources folder of the app Handbrake.

res_hb

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.

@DivingDuck
Copy link
Collaborator Author

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.

@DivingDuck
Copy link
Collaborator Author

New updates:

  • Merge latest changes from master branch
  • pronsole.py:
    Update the log string as mentioned
  • utils.py:
    macOS: search translation folder and files on the same place where the binary file is located, it acts now same as for Windows
  • README.md:
    Update chapter Translating Pronterface, add information where Pronterface look for translation files
  • Update all translation files:
    Because of code changes and change one menu string for platter in German translation to be more specific.
  • release_windows.bat:
    Add copy README.md to the distribution folder

Latest artifacts:
Windows: https://github.com/kliment/Printrun/actions/runs/13393302186
MacOS: https://github.com/kliment/Printrun/actions/runs/13393302187
Wheels: https://github.com/kliment/Printrun/actions/runs/13393302161

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

@rockstorm101
Copy link
Collaborator

Thanks for your efforts here. Unless @neofelis2X wants to add anything I'm happy to merge now.

@neofelis2X
Copy link
Collaborator

Nope, i have nothing to add, looks great!

@rockstorm101 rockstorm101 merged commit 9ff2df6 into kliment:master Feb 20, 2025
19 checks passed
@rockstorm101
Copy link
Collaborator

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.

@DivingDuck
Copy link
Collaborator Author

DivingDuck commented Feb 21, 2025

@rockstorm101, I try to do so next time. 😇
I thought the same somewhen beginning this month, but was also surprised about all the changes needed for the change to py 3.13.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

macOS 12 will be deprecated as a build environment
3 participants