CI actions not working as expected

[rockstorm101]

Latest release did not trigger neither Windows nor macOS apps builds. I believe the following change might help but can't really test GitHub actions. Might have been my bad because I created the tag before the release and I used to do both things at the same time.

on:
  push:
  pull_request:
  release:
    types:
-      - created
+      - published

Also something needs fixing regarding the uploading to PyPI. Last attempt threw the following error. I'll contact @kliment see if we can work something out.

25hWARNING  Error during upload. Retry with the --verbose option for more details. 
ERROR    HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/        
         User 'kliment' does not have a verified primary email address. Please  
         add a verified primary email before attempting to upload to PyPI. See  
         https://pypi.org/help/#verified-email for more information.

[kliment]

Account on pypi is now verified

[DivingDuck]

Upload_pypi runs after re-run the job. Maybe we need to re-run all jobs once more?

[DivingDuck]

I couldn't resist and re-run all job's with debug information activated. It seems everything runs fine except uploading to upload_pypi (what I have expect). It looks like one of you need to restart the job.

https://github.com/kliment/Printrun/actions/runs/9245207731/job/25486667830, log#3, Line 92 + 93

##[debug]Using a user-provided API token for authentication against https://upload.pypi.org/legacy/
Warning: Trusted Publishers allows publishing packages to PyPI from automated environments like GitHub Actions without needing to use username/password combinations or API tokens to authenticate with PyPI. Read more: https://docs.pypi.org/trusted-publishers

and line 174 to 177

25hWARNING  Error during upload. Retry with the --verbose option for more details. 
ERROR    HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/        
         File already exists. See https://pypi.org/help/#file-name-reuse for    
         more information.       

[kliment]

You're trying to upload the same version you already uploaded. It will fail by design.

[rockstorm101]

Second attempt at building and uploading the wheels did run fine. So everything is up to date now on PyPI. So that bit is fixed. We'll see on next release whether the actions that build the Win/macOS apps work flawlessly.

[DivingDuck]

How did you attach the files? I missed that step

[rockstorm101]

How did you attach the files? I missed that step

I had to do that manually I'm afraid 🥲

[khipp]

The binary for macOS 11 is missing from the 2.1.0 release. Has support been dropped, or will it still be added?

[DivingDuck]

@khipp,
Indeed, we removed macOS11 from the build and I can't remember why. Can you please test this build below and report back?

https://github.com/DivingDuck/Printrun/actions/runs/9286412163

I will post a new PR for the workflow if the macOS-11 version is working for you.

Best regards,
DD

[khipp]

@DivingDuck
Thanks. Unfortunately, I don't have a way to directly test the binary for macOS 11. I could only trigger the CI test if the binary is added to the release assets.

[rockstorm101]

Indeed, we removed macOS11 from the build and I can't remember why.

Removal of the macOS 11 build occurred as part of PR #1407. Allegedly, the Python wheels produced using macOS 11 and macOS 12 runners where identical. So I guess the app/zip was thought to be identical as well for both and therefore one could be removed. If that's not the case, it would be super easy to reinstate the build.

Please forgive my ignorance here, can you run the macOS 12 app/zip currently released on a macOS 11 system?

[khipp]

Please forgive my ignorance here, can you run the macOS 12 app/zip currently released on a macOS 11 system?

I reran the tests for macOS 11 by substituting with the binary for macOS 12. No issues were reported (see run).

[DivingDuck]

Removal of the macOS 11 build occurred as part of PR #1407.

Ah, I forgot that. This makes sense.

[khipp]

The Homebrew installation script has been updated to only use the macOS 12 version going forward. Thanks, everyone!

[rockstorm101]

What are your thoughts on reinstating the macOS 11 to avoid people thinking we dropped support?

[neofelis2X]

Currently the release file is called printrun-2.1.0_macos-12_x64_py3.10.zip
I guess you could avoid this confusion by omitting the 12 and just name it: printrun-2.1.0_macos_x64_py3.10.zip

Also, Printrun still supports python 3.8? The _py3.10 in the name might make people think they need that particular version.

[rockstorm101]

Currently the release file is called printrun-2.1.0_macos-12_x64_py3.10.zip I guess you could avoid this confusion by omitting the 12 and just name it: printrun-2.1.0_macos_x64_py3.10.zip

Also, Printrun still supports python 3.8? The _py3.10 in the name might make people think they need that particular version.

Please forgive my ignorance regarding macOS stuff. Currently the CI runner uses macOS 12 and python 3.10 to build the macOS app. Could this application be run on say macOS 11 with Python 3.8? My current understanding is the OS version does not make a difference but regarding Python it doesn't work "backwards". So maybe we need to build with Python 3.8 instead? And as you suggest, remove the bits about OS and Python versions.

[DivingDuck]

Also, Printrun still supports python 3.8?

Yes, this is the latest version where we can support binaries for 32 bit Windows in combination with module pillow. Having the python version was in the past helpful to identify compatibility problems in some modules like wxpython.

A question I had in the past was, is it somehow possible to identify how many downloads we had for all different OS packages we offer? This is maybe helpful to know.

For macOS12 vs 11 I'm unbiased. We should at least wrote in the description that it support macOS 11 and 12.
☺

[neofelis2X]

Please forgive my ignorance regarding macOS stuff.

No ignorance at all! :)
OS: Yes, so it seems it is backwards compatible to macOS 11. And it definitely works from 12 to all the way to the latest macOS 14.5.
python: I was a bit confused for a moment, but pyinstaller actually packages up the python version it is used with. So the user doesn't even need to have any python installed. No need to change the build of the macos release to py3.8. :)

I honestly do not have a strong opinion how the naming should be. But changing macos-12 to macos makes sense to me.

An by the way, GitHub will deprecate the macos11 runner:
The macos-11 label has been deprecated and will no longer be available after 28 June 2024.

is it somehow possible to identify how many downloads we had

This website outputs some stats about the downloads. Pretty interesting.
https://somsubhra.github.io/github-release-stats/?username=kliment&repository=printrun&page=1&per_page=5

[DivingDuck]

Yes indeed. Hadn't expect so much downloads in such a short time frame. Only Linux is a black box.
Here are some additional information from PyPi I found yesterday:
https://pypistats.org/packages/printrun

[rockstorm101]

Thank you both for those links. So interesting. Can't get my head around how someone other than GitHub/PyPI has access to information that (in my mind) is only available within GitHub/PyPI servers XD

OS: Yes, so it seems it is backwards compatible to macOS 11. And it definitely works from 12 to all the way to the latest macOS 14.5.
python: I was a bit confused for a moment, but pyinstaller actually packages up the python version it is used with. So the user doesn't even need to have any python installed. No need to change the build of the macos release to py3.8. :)

Awesome, thanks. Let's remove those from the file name then. And last but not least, I guess the architecture bit must be kept as 'x64'. Or would the app work on apple chips too?

Having the python version was in the past helpful to identify compatibility problems in some modules like wxpython.

Agreed. I would only remove those on the "release" files but keep the full name with all its bits for the nightly/testing ones as proposed in #1432

[neofelis2X]

I guess the architecture bit must be kept as 'x64'. Or would the app work on apple chips too?

pyinstaller produces an intel binary at the moment (x86_64) and it works on the arm apple chips because of the rosetta2 translation layer. That is okay, no need to change anything. If you want to, tho, you could try set up an arm64 runner and produce a native binary for this platform. ;) Or maybe I test it on my repo, when I have some time left.