I'm going to ask a 'self-taught' question, so my terms may be incorrect.<p>Has anyone solved the compiled libraries / dynamic libraries / linking problems for multiplatform apps? Everything works just fine with these python>native app tools until you hit some esoteric library that's not pure python.
> If you’re on Linux, you should use the system Python provided by your operating system. You will be able to complete most of this tutorial using a non-system Python, but you won’t be able to package your application for distribution to others.<p>Why not?
I’ve had a lot of experience with another similar library, Kivy (kivy.org). These types of libraries, can be quite effective for the right use case. I shipped a couple mobile apps on both Google and Apple, so there’s that. I would check this out, but I do remember having to work through a lot of issues to get the mobile build just right. I wonder if a less mature project like this would have similar struggles?
Although I have never used any of their stuff, I had the pleasure of watching Russell from BeeWare at Pycon Colombia some years ago. It consistently presents itsself as an ecosystem I would like to work with, and if anything the naming of their projects is very nice.<p><a href="https://www.youtube.com/watch?v=TY4vb6V-gvc">https://www.youtube.com/watch?v=TY4vb6V-gvc</a>
Anyone happened to use Toga with video streams? I've got some gstreamer stuff with Qt and it doesn't need a rewrite yet but it's a glimmer on the horizon.
Interesting timing! We're just in the middle of adding Python support to Hydraulic Conveyor, which is a similar tool [1]. There's a github issue [2] and mailing list that'll get notified when it's done. Disclosure: it's commercial but free for open source projects.<p>There are many of these open source packagers and they all share very similar problems:<p>1. They don't let you do software updates, even though software updates are practically mandatory for any real project. Electron is a stand-out here because it does address this, but their update engines are unmaintained for years and have some major unfixed problems (causes a lot of issues with Windows networks, for example).<p>2. Even in the very rare cases that they do, they don't let you force updates on launch even though many apps need something like this to keep up with protocol changes. It's one of the reasons people like web apps.<p>3. They don't help you with signing. For example they don't simplify key management, they don't support cloud signing (essential since May because Microsoft now insist on HSMs for all keys, not just EV keys), or they don't do notarization, or they don't generate CSRs for you.<p>4. They require the use of CI to cross-build even when apps are written in portable frameworks that don't require compilation. This is because they are just thin wrappers around the native tooling.<p>5. They're invariably language specific even though there's no good reason to be because 80% of the work is the same regardless of what language or framework you use.<p>6. They make MSI files for Windows even though MSI is deprecated.<p>It's possible to bite the bullet, chew glass for a while and solve all these problems, which is what we did for Electron/JVM/Flutter/native apps. You can reimplement all the native tooling so users can cross-build (i.e. make Mac packages from Linux/Windows, Windows packages from Mac/Linux etc), which enables releasing from developer laptops or cheap Linux CI workers. You can support software update by integrating Sparkle on macOS, apt on Debian/Ubuntu and by using MSIX on Windows (and by then working around all the bugs in Windows to make it work well). You can generate download pages that work out the user's OS and gives them the right download, and instructions for how to install self-signed apps if the developer isn't code signing with a recognized certificate. You can abstract platform neutral things and expose platform specific things. Then you can write a parallel incremental build system so doing all the work is as fast as possible, and write lots of code to detect all the myriad mistakes people make and give good error messages or auto-fix them. Then you can make it support GitHub Releases. Then you can document it all.<p>But that big pile of glass isn't particularly tasty, which is why open source projects don't do it and we ask commercial users to pay for it.<p>Briefcase looks nice but it also seems to have all the problems listed above. I think once we add Python support Conveyor will be quite useful for the Python community, especially if we can find a workaround for pip not support cross-building of venvs. It would be great if you could just whip up a quick Python script, run one command and your installed clients start automatically updating, your download page updates, and the whole thing is no harder than releasing a static markdown-rendered website.<p>[1] <a href="https://hydraulic.dev/" rel="nofollow noreferrer">https://hydraulic.dev/</a><p>[2] <a href="https://github.com/hydraulic-software/conveyor/issues/73">https://github.com/hydraulic-software/conveyor/issues/73</a>