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

Remove cairosvg and submodule PrintrunGTK3 from windows build process #1400

Merged
merged 15 commits into from
Jan 10, 2024

Conversation

DivingDuck
Copy link
Collaborator

@DivingDuck DivingDuck commented Dec 25, 2023

With former pull request #1387 (2023-11-20) for projector we no longer need:
VERSION (file), PrintrunGTK3 (submodule), cffi, cairocffi and cairosvg.

In addition I add support for x86 (32-bit windows version) and Python version 3.11.
The console program Pronsole.exe was missed for long time. It is now back and part of the windows executable file set in our repository. I split the file set (pronterface.exe and pronsole.exe) into a x86 and x64 downloadable version.

Changed files:
Buildpackage_win.yml
pypi-win.yml
Buildinstructions.txt
release_windows.bat
requirements.txt

Pillow version needs to be < 10.0 for x86 builds of 32-bit wheels (needed for build of wxPython).
10.x do not support x86 any longer.
With Python 3.12 we final need to drop Windows x86 builds. Further information can be found here.
--> https://pillow.readthedocs.io/en/latest/releasenotes/10.0.0.html#bit-wheels
--> https://pillow.readthedocs.io/en/stable/installation.html

Modifications in detail:

Buildpackage_win.yml:
-remove submodule PrintrunGTK3
-remove cffi from Install dependencies
-remove from all builds: --add-binary "PrintrunGTK3/GTK3Windows10-64/*.dll;." --add-data "VERSION;cairocffi" --add-data "VERSION;cairosvg"
-remove from x86 builds all wxPython exceptions for older python versions
-only one build path for x86 will remain to test x86 version with new wxPython 4.2.1 and its new x86 builds
-for x64 and x86 retain the possibility to compile with different development versions of wxPython if we need to act for x86 or x64 builds
-Add x86 build again
Attention: Minimum version for x86 build needs to be wxPython >= 4.2.1 (2023-11-20)
-Add Python 3.11

pypi-win.yml:
-add python 3.11

requirments.txt:
-remove cffi, cairocffi, cairosvg
-add pillow < 10.0; sys_platform == 'win32'
This is needed to build 32-bit version of wxpython as they use pillow.

release_windows.bat
-add python 3.11 venv
-remove cairosvg workaround
-remove cairocffi, VERSION, submodule PrintrunGTK3 binaries from build process
-remove all build process versions for GTK3 x64,x86 as no longer needed.
-mark Plater standalone application as experimental and not completed for now.
-With wxPpthon 4.2.1 we can build x86 applications again. Remove of x64 only in
comments (point 4.) and how to add the submodule PrintrunGTK3
-restrict Python x86 version between 3.9 and 3.11 as Polygon3 and Pillow seems to have problems with py 3.8
-add pillow workaround for pillow < 10.0

Remove submodule PrintrunGTK3

Remove file VERSION
This was a dummy file for pyinstaller to compile Pronterface. Cairocffi and cairosvg won't find
the GTK3 runtime libraries needed for running Projector under Windows w/o this file. No longer needed.

General Question:
When should we remove old not longer serviced Python versions (3.7 to 3.8) in pypi-win.yml? We don't need them in our github builds (at least for windows) as support for external modules is not longer given (like wxPython/Pillow).

Edit:
I do not expect problems with non Windows versions as the changes belong to windows builds, but we better check this.

(install python extension compile environment, see https://wiki.python.org/moin/WindowsCompilers )
(install git)
git clone http://github.com/kliment/Printrun.git
cd Printrun
git submodule update --init --recursive
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line would not be required since there won't be a submodule any more?

@rockstorm101
Copy link
Collaborator

Thank you for this detailed changes explanation. Very helpful.

General Question:
When should we remove old not longer serviced Python versions (3.7 to 3.8) in pypi-win.yml? We don't need them in our github builds (at least for windows) as support for external modules is not longer given (like wxPython/Pillow).

Isn't Python 3.8 still supported by both wxPython and Pillow? I can see wheels for Python 3.8 on PyPI. On the other hand, you are right that 3.7 seems not supported even though it is listed as if it were so I guess it should be removed on our end as well.

@DivingDuck
Copy link
Collaborator Author

buildinstructions.txt:
Yes, indeed. Guess this file do need some more updates for windows and maybe for other OS as well. I haven't look too deep in it and had only fix the python version and then forgot to look in it again. I should do better...
Have you some additional remarks for Linux and MacOS so I can update this as well?

readme.md:
In addition we need to change the instructions for Windows build as well. I plan to change this as soon there is no other missing thing comes up.

Python3.8:
I was able to build a x64 version but I was not able to build the x86 version with Python 3.8 and pillow 9.5 since now. Therefore I did restrict the manual builds with release_windows.bat for x86 builds to versions between 3.9-3.11. It becomes more and more complicated to find matching module versions used in our build process for windows. It looks like we run for other supported OS into the same situation more sooner than later. This was why I thought we should cut Python 3.8 for Github builds with Windows as well. One who want to make the exercise for Windows can do this local with release_windows.bat, but with Github actions we should not do this. The process is for my opinion too fragile and with each update we will have more risk that something will brake. I was worrying already with reactivating a x86 build but I think this is the last chance having an updated official x86 build for those with restricted hardware.
Anyway, if I find a solution for Python 3.8 in the future, I can add it back again. Like I did for x86. This happen only because wxPython add x86 support back again for version 4.2.1.

Had you a chance to run the code for Linux and MacOS?

Off topic:
I plan to update the translation files in a separate pull request as well. Is there something why I should wait, e.g. some additional changes you want to add soon? I recognized some missing translations for Pronsole and we should delete the separate translation file for Plater as this was already merged into the main translation file after the last release. I plan to do it as soon this pull request is implemented.

@rockstorm101
Copy link
Collaborator

buildinstructions.txt:
Have you some additional remarks for Linux and MacOS so I can update this as well?

To be honest, I never looked at this file in past. If we think it is still useful, we probably should merge the usefull bits onto the main README file or, if we did not want to clutter the README, at least upgrade this document to a proper Markdown format and point to it from the main README. As far as this PR goes, I'm happy to leave it as it is now, it can be dealt with later. Thoughts? Did you use this file at all?

Python3.8:
I was able to build a x64 version but I was not able to build the x86 version with Python 3.8 and pillow 9.5 since now.

Fair enough. Maybe we can just exclude the combination of Python 3.8 and x86 arch on pypi-win.yml? If it is too much work to support 3.8 on Windows I'm of course happy to take it out. For Linux and MacOS I would leave it for as long as we can, just in case, in a effort to support people with old systems. But again, resources are scarce, so maintainability must be prioritized over support.

Had you a chance to run the code for Linux and MacOS?

The machines I've got at home run Python 3.9 or newer, so I can't really print anything using the 3.8 builds on Linux. "The basic automated test passes" is the best I can say :P

I plan to update the translation files in a separate pull request as well. Is there something why I should wait, e.g. some additional changes you want to add soon? I recognized some missing translations for Pronsole and we should delete the separate translation file for Plater as this was already merged into the main translation file after the last release. I plan to do it as soon this pull request is implemented.

No, there aren't any showstoppers that I know of. All yours, please go ahead. I agree with the merging of Plater as well.

@DivingDuck
Copy link
Collaborator Author

DivingDuck commented Dec 27, 2023

Thoughts? Did you use this file at all?

I didn't use this file too, but maybe other users. I converted it in a markup file and did some more corrections

Regarding Python 3.8

We can leave it at 3.8 in place and delete only 3.7 from pypi-win.yml and buildpackage-win.yml in a first step. In the end it doesn't matter as we build only 3.10 versions per default for now and in case we activate 3.8 it will build only the x64 version successful. We can take a second look on this later. :)

List of additional changes:
Buildinstructions.txt:
-convert Buildinstructions.txt into Buildinstructions.md
-change default Python version to 3.10
-remove submodule PrintrunGTK3
-remove cffi for osx and windows
-add a hint for further information in release_windows.bat
-add missing libraries for windows (wheel, simplejson, pypiwin32 and polygon3)
-add a remark for polygon3 license information

Readme.md
-remove submodule PrintrunGTK3 for Windows builds
-add a hint for using pronsole.exe with windows terminal

@rockstorm101
Copy link
Collaborator

I converted it in a markup file and did some more corrections

Love it. Thanks for your work here.

We can leave it at 3.8 in place and delete only 3.7 from pypi-win.yml and buildpackage-win.yml in a first step. In the end it doesn't matter as we build only 3.10 versions per default for now and in case we activate 3.8 it will build only the x64 version successful. We can take a second look on this later. :)

I'm happy with this as well. Agreed.

@DivingDuck
Copy link
Collaborator Author

DivingDuck commented Jan 9, 2024

This is the last change/part for this request.
Meanwhile I tried to find a solution for Python 3.8-32 and Polygon3 support, but had no success. So I leave it as it is and do only support x86 versions starting from Python 3.9. In the table below are all possible build combinations which are supported by now.

Python x86 x64
3.8 - x
3.9 x x
3.10 x x
3.11 x x

@rockstorm101 rockstorm101 merged commit 69bed06 into kliment:master Jan 10, 2024
26 checks passed
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.

2 participants