Repo Improvements

[bastisawesome]

With the initial commit, this resolves automated linting with both Flake8 and MyPy, as well as running tests on Linux.

When finalised, this PR closes #6.

[bastisawesome]

An important note about this PR: currently the testing framework has known problems with MyPy, so any PRs that make code changes will instantly fail.

[bastisawesome]

Update on this PR: this PR is now targeting all of the code-related issues (not including documentation-related issues) marked for the "Repo Improvement" milestone. The documentation updates will be handled in a future PR.

Specifically, this PR will resolve the following issues:

• Resolves #6
• Resolves #38

While there's only one extra issue added to the list, there are several steps that have to be taken that were not split into separate issues (see #6). There was also one issue never officially created, but prior to this comment has been resolved:

The project now contains an automated versioning system, and a new version flag to the application. Necessary to work on the automated release builds, as the builds will need version information, and the application has had no means of checking the version until now.

[bastisawesome]

Reminder to update the readme to include build information about using the script, and to include the script in Pipenv so it can be run outside a venv shell.

[bastisawesome]

As of the previous commit, confirmed the build script works on all 3 major supported platforms!

[bastisawesome]

With that last commit, this PR should be ready for testing. Everything should be finished and merged once confirmation that the workflows are correct.

Upon completion, the following issues will be resolved:

• 6

• 38

[bastisawesome]

Wow, it has been... Nearly a year of development hell and in that time virtually no code has been written. This is mostly just documentation for future me, but maybe someone else in the future can share some better insights or perhaps things will change and I can bring this back.

A quick background:

In the past year I have been looking into ways to make this solution work. I wanted to automate generating standalone executables of the bot for all major platforms, including the Pi 0w up to Pi 4 (with Pi 0w being enough to run on a 3B+). The ARM builders have always been the biggest hurdle, although the Windows builder has been pretty awful as well, locking me out of seeing if Windows is the problem or if my build scripts and configs are broken for all platforms (Windows blocked the Linux and MacOS runners). What I've found is that the ARM runner is just plain broken, and it doesn't provide the necessary diagnostics for me to reasonably troubleshoot, from the logs it almost looks like the runner just doesn't work.

Even worse, the runner for PyInstaller also doesn't support the ARM runner, so this entire process was a waste of time. And for almost a year I've been looking into every element of the automation workflow and finding that it just won't work, and likely never will. This is the conclusion I've come to, with no real evidence to prove it wrong, but if I missed something then I can revisit this idea. And that has been a lot of what I've been doing.

So where we go from here:

Of course, trying to get the workflow wasn't the only solution I had in mind. My first thought, and I reached out to a few people to get their opinions on this, was that I could simply rewrite the entire project in Rust (ugh, why...). Worst case scenario, depending on what the Rust runners look like, it's incredibly simple to get a cross-compiler toolchain for Rust. This meant I could build for all platforms using Cargo locally, then upload each artefact manually. However, GGTTV took me over a month to write in Python, a language I am intimately familiar with, and with another month dedicated to planning the project (on the upside, I have the reference source so at least I don't have to go through that again).

Rust is a language I'm not only widely unfamiliar with, it's a language I am averse to simply because it goes against a lot of my experience and thinking. I find that writing Rust feels like I'm fighting the language itself rather than working alongside it. And because I'm never really sure what the "right" way to do anything is (and trust me, doing things the wrong way just leads to a lot of spaghetti and compiler errors), it would take me far longer to rewrite the entire project. On top of this, the Crates for interacting with Twitch are... Not in good states. Most of the top ones haven't received an update in 4 years (that's prior to the Helix API!), and the ones that have lack a lot of the features I enjoy from the Python module I'm using now.

All of this to say, rewriting the bot in Rust is not happening. I'm not a proponent of rewriting projects for the sake of porting to Rust with no actual, meaningful changes (ripgrep anyone?), but in this case it felt mildly justified if it eased the aspect of automating the build system for all platforms I intend to support. And the general response I got from others was effectively do whatever I feel is right. Thanks...

So finally, the only other solution I came to. I'll admit, I wasn't happy with the idea at first. GitHub has a way to self-host Action environments, but I don't think I want that (right now, at least). However, QEMU is relatively easy to setup for something like this, so I could just... Have QEMU images for every platform and run the builder in each environment! Except MacOS... I'm afraid I may just not support that for the time being, right now I just need to be in a position to write code and making a hybrid system is out of scope, at least until the next major release.

MacOS support is going away for now, but Windows is possible due to a Windows 10 testing VM I already have setup to build. That can't be automated unless I migrate to QEMU (I dunno, someone will probably tell me it's very easy, I'll disagree), but I find Windows to be unpleasant anyway, so I'll just manually build that. Linux is easy, it's what I daily-drive, and those builds seem to Just Work™. The ARM stuff? QEMU has support for RPi systems, so I can spin up a machine, run the build scripts, grab the artefacts, and then upload them. Windows, once again, being the outlier.

All of this to say, this PR is being closed but may be reopened in the future if the state of things change. Or perhaps in the future I will configure a system to act as a local runner for GitHub Actions so I can automate through their API.