Build executable as part of build

[Koenvh1]

Hello!

I am using this SDK with a lot of success - it works really well. However, the method for sharing seems a bit finicky (requiring the user to have Python installed, creating a venv, running pip, etc.), so I replaced that part with a binary created by PyInstaller. The disadvantages are that the size is quite a bit bigger and that it is not cross-platform (although with GitHub Actions that last one can probably be solved). The result of that can be found here: https://github.com/Koenvh1/ScreenDeck

Would you be interested in getting that somehow included in the build tooling? I should be able to make a PR if you are.

[gri-gus]

Hello, @Koenvh1 ! It's cool that the tool helps you. And it's great that you were able to figure it out, with almost no documentation that I haven't completed yet... By the way, I am working on a new SDK version with the addition of new Streamdeck API functions, so the project has not been abandoned. I will try to explain why the approach without binary files is currently chosen.

Let's outline the limitations and comment on them:

1. Most developers are lazy, myself included. That's why we try to automate or simplify things; that's why we're developers. Many developers write great code for other people, for the companies they work for, but they rarely write anything for their own convenience. Why? Because they're lazy. I'm a bit different here, as I try to make the work comfortable and not cause too much inconvenience. But even I'm often too lazy to write something, or simply don't have the time. Conclusion: a tool must be as simple as possible in terms of coding; otherwise, no matter how good an idea for a plugin, in most cases it simply won't be implemented and will remain just an idea.
2. We have the wonderful Python, which I love very much. But it's interpreted, which is why I also hate it. And we can't yet create small binaries like compiled languages. That's why even your plugin weighs 118 MB, even though it doesn't have any heavy dependencies. For example, I have about 13 plugins written in Python, which would weigh several gigabytes if I packaged them with PyInstaller. I think that's a bit much for plugins. And considering that each plugin has an interpreter built into it, it seems like a mistake.
3. Streamdeck can only run sh or bat or binary files , when it comes to plugins. Therefore, it won't be possible to run a Python file without an intermediate file or without packaging it into a binary file.
4. The dependencies for Windows and MacOS are different, and they're also different for different processor architectures (for example, Intel and Apple Silicon on MacOS). Should I build for both operating systems and for each processor architecture? Should I have a stack of laptops on hand for the build, or rent virtual servers? I think point 1 will answer this question. What about Docker? It's unlikely to help in this case; I've thought about it. It's probably easier for a user to install Python than to figure out Docker. But what about GitHub Actions? The answer is in the next point.
5. Not all plugins need to be public and posted on GitHub. I'd say 90% of plugins won't be uploaded to GitHub. Therefore, GitHub Actions won't work everywhere. I don't see any simple and universal ways to create binaries for different operating systems and processor architectures yet.
6. Personally, I have a situation that I encounter all the time: I need to quickly create a plugin that I'll use constantly. Such a plugin would save a lot of time. And I need it right here and now. It also needs to be available for macOS on Apple Silicon (my main laptop) and for Windows (my secondary computer). I can refine the plugin later, but the first working version needs to be released as soon as possible. Will I have the desire and time to deal with dependencies, do a bunch of builds, etc.? I think not. I'll likely be overwhelmed by the complexity of this process, and the desire to create a plugin will fade (point 1). And if I need to share it with colleagues who also write Python, I'll have to ensure it works for them too. In this scenario, PyInstaller and similar tools seem too labor-intensive in terms of building for different platforms.
7. Streamdeck encourages learning HTML and JS to create a Property Inspector. Back to point 1: laziness. And I don't think all Python developers should know them to the level necessary to write plugins. We write Python—give us Python. That's why we created a tool for creating Property Inspectors using Python.
8. Streamdeck doesn't support Python out of the box, so some of the solutions in this SDK are workarounds. But it works.

From all of this, we can formulate some requirements for the tool:

1. The tool should be as simple to code as possible given Streamdeck's plugin requirements.
2. The tool should be capable of creating complex, large plugins without sacrificing its simplicity.
3. If possible, the resulting plugin should take up as little space as possible. (The current method allows you to achieve this.)
4. The resulting plugin should contain a sh or bat file, or be a binary file for execution.
5. The tool should be platform-independent, neither the one the code is written on nor the one for which it is written.
6. Ideally, the plugin user should perform as few steps as possible to install and run it. (Python is already preinstalled on MacOS, and for Windows, it wouldn't hurt to install it, especially since it only needs to be installed once.)
7. Ideally, knowledge of Python should be the only language required to write the plugin.

I think this SDK meets most of the requirements. Regarding venv and requirements: In the current implementation, users must have internet access upon first launch, and this is a limitation I'm considering how to work around, but there are some very difficult issues to overcome. Even in the current situation, a MacOS user (Python comes pre-installed) can click the plugin, and it will automatically create a virtual environment, install dependencies, and launch upon first launch. This all happens in the init.py file. Therefore, no manual intervention is required. Windows users only need to install Python once; otherwise, the process is the same. The Internet is only needed for the first launch. Simple? It seems fairly simple to me. Wouldn't it be ideal to do it perfectly, without relying on Python or the internet? Yes, but given the limitations, that would greatly increase the developer's complexity, especially considering the situation outlined in point 6 of the limitations.

Will tools for building binary files be added in the future? Possibly. This would be useful if you really want to create a plugin that will be a full-fledged product used by at least hundreds of people. But in that case, I don't think Python is the best choice, unfortunately.