Closed gavinhenderson closed 2 months ago
Note for later is that some software that could be used is this. https://github.com/dennisvang/tufup
@sjjhsjjh check out the workflow at https://github.com/AceCentre/FaceCommander/blob/main/.github/workflows/windows-build-release.yml - basically it builds the whole thing and installer. I think we should ditch the portable - I didnt really test that and if Im honest I think it will break because of the filepaths that I put it to local for it in your LOCALAPPDATA type dirs.
But its largely there. But yeah - tufup looks good. I looked into that.
Thanks Will, Should we decommission the portable piece as part of this work, Issue #7, then?
My gut feeling is to say yes to that. Having effectively two builds - or two build steps is a bit of a hassle.
Thanks Will, I looked at the yaml and can see that it builds the executable and installer. It's triggered by pushing a tag with a particular format. I don't see how to fit in the signed installer piece that @gavinhenderson mentioned.
Ahh you don't
Our signing process is a bit of a pain as we have a physical key that needs to sign it.
Hi, I had a bit of a think and reckon these are the required pieces.
On balance I don't think we need to implement any integrity checking. We can rely on the operating system and signing to do that. The highlight-download-run pieces represent the most common use case, which is to install a new release of the app. The releases page piece supports less common use cases such as these.
What do you think?
Yeah. I was having a good look at tufup. It’s pretty decent but you do look like you have to do a bunch of work on the repo handling / server side. Although I could be wrong. I’ve only skim read this (/ had a go at converting their power shell script for Mac https://github.com/dennisvang/tufup-example/pull/26#issuecomment-2053740246 ) see https://github.com/dennisvang/tufup-example/tree/master/src And this for the init scripts etc. https://github.com/dennisvang/tufup-example/tree/master
this is where electron is better.
Your idea seems sound to me Jim. The one downside is it won’t force updates - but then Our users are used to this approach in grid etc . @gavinhenderson ?
One last idea is beeware.. Its pretty decent although not that common. Take a look at https://docs.beeware.org/en/latest/tutorial/tutorial-4.html for autoupdating. Builds on Multiplatform too - not thats our angle right now. It also packages as a MSI which is often more desirable for sysadmins etc..
see also https://briefcase.readthedocs.io/en/stable/how-to/index.html
Thanks Will, Having multiple types of installer seems to be quite common. So if MSI will support some use cases that .exe doesn't then I don't see a problem. I'm unsure about forcing upgrade. It's OK if FaceCommander remains usable while the upgrade is in progress. Otherwise I think users need to control when the upgrade happens.
@sjjhsjjh
I really like that approach! It moves a lot of the hard work out of the app while keeping the user experience really smooth. I also like that as you highlight its it will still support the other less common user journeys.
I say go for it! :)
Okey dokey I might build some test releases just to have something to work with if that's OK?
Hi, Here's an interim update for today.
At CoP the new build is working. I have tested the .exe installer. Sorry, I had to do a lot of commits to try things out in the workflow.
Never apologise about the number of commits. You want to see the number of commits (and timespan) I have on some of these GH workflows. Nice one Jim
This is brilliant work @sjjhsjjh!
Its probably already on your radar but it would be good to have the process documented briefly in the README. Mainly thinking about myself coming to this project in a few years and needing to remember how to do a release 🤦♂️
Hi, Here's another interim update.
So I'll be adopting that library into FaceCommander in due course maybe tomorrow. After that my plan is to add some Tk variables to the UpdateManager. That seems to be the correct way to have an observable state that can be updated from a download thread and then reflected in the UI.
Awesome work @sjjhsjjh !
We are going to have one of the best update experiences around!
At close of play I have proof-of-concept code pushed for
So, bit of a hiccough encountered today. The observable status message is true but isn't multi-threaded. Specifically, a tkinter.StringVar or IntVar cannot be set from a thread other than the main thread that runs the UI. That seems to mean the app will need to poll the UpdateManager singleton's state from the tk mainloop. One place there's already some polling is in the MainApp declared in the face_commander.py file. I can add UpdateManager polling there, unless there's some reason not to or a better place?
Hi, Update for today is that this branch now has these features.
Remaining pieces are as follows.
Hi, These pieces are now done on the branch.
This piece isn't done.
Also to-do is the developer documentation.
Evocative descriptions are done.
Awesome work @sjjhsjjh !
I have created a PR from your branch so I can easily look over the code etc: https://github.com/AceCentre/FaceCommander/pull/24
I'll have a quick play around and then merge into main unless I have any issues, which I doubt I will.
My plan this week is to try and get a handle on the admin stuff then once we have all that done we can start getting users onto it and then we can just iterate from there (thanks to your updating mechanism)
Thanks Gavin, I'm not sure myself that it's ready but I recorded a video here. https://youtu.be/dyTzdQpYpmM?si=XTnxKcCubCJHFC2a
If that all looks ok I'll write the developer documentation.
Thanks Gavin, I'm not sure myself that it's ready but I recorded a video here. https://youtu.be/dyTzdQpYpmM?si=XTnxKcCubCJHFC2a
If that all looks ok I'll write the developer documentation.
Wow. That's stellar Jim!
Ideally we would have a github action that can be triggered and will create a new release on github with an installer. We (Ace Centre) can then sign those installers, although that has to be done manually as we have to use a physical key in the process.
We also want it to be easier for users to update. It doesn't have to be automatic but they should be able to update to the latest version easily.
This maybe already works but it just needs checked