8 ms·

Briefcase: Convert a Python project into a standalone native application

182 points by generichuman 3y ago

nu11ptr 3y ago
How does this compare to PyInstaller or other packagers? What underlying tech does it use?
- WillAdams 3y ago
  The big difference is it uses "Toga" https://beeware.org/project/projects/libraries/toga/ https://beeware.org/project/projects/libraries/toga/ which uses native widgets and manages basic functionality such as where the "Quit" menu entry is automatically. Looking into this now --- it looks perfect for my needs, just hoping that there's a nice graphical tool for laying out a GUI (if it has a graphical programming mode like to Blockly or Ryven, then it is perfect for me).
  - fock 3y ago
    so essentially what Kivy did already a bit ago.
    - nbadg 3y ago
      I haven't used Kivy in quite a while, so maybe this has changed, but as far as I know -- no, Kivy hasn't done something like this. In Kivy, everything looks like Kivy, regardless of what platform you're on, and you need to explicitly lay everything out, including whichever changes you want for a particular platform. Whereas with Toga, the UI is changed to match the user's expectations for that platform, automatically. One example of this, as parent mentioned, is where the "quit" button is located. Different platforms put this in different places. Toga will automatically put it in the right one, depending on which platform you're on. Buttons will look like normal buttons on a Mac, but also like normal buttons on Windows -- depending on which platform you're on.
      - dr_kiszonka 3y ago
        Hi! Do you know whether Kivy or Toga/BeeWare lets you access Android API? For example, I want my app to listen to BatteryManager's broadcasts [0]. Is it possible using any of these frameworks? (Or any other Python-centric framework?) I read that Toga supports background tasks, but it is not clear to me if I could use them to listen to Android broadcasts. 0. https://developer.android.com/training/monitoring-device-state/battery-monitoring https://developer.android.com/training/monitoring-device-sta...
        WillAdams 3y ago
        They give an example of using Apple's Obj-C framework, so I believe this sort of thing is possible.
- skinner927 3y ago
  It appears PyInstaller is much more portable. Briefcase seems to make an .msi installer on Windows and an AppImage for Linux. Both of those require installation to use. PyInstaller can create a single executable that you can just run (yea sure it extracts itself to a temp dir, but the optics are very different).
mvdwoord 3y ago
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. https://www.youtube.com/watch?v=TY4vb6V-gvc https://www.youtube.com/watch?v=TY4vb6V-gvc
deleted 3y ago
[deleted]
velosol 3y ago
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.
mike_hearn 3y ago
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. There are many of these open source packagers and they all share very similar problems: 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). 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. 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. 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. 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. 6. They make MSI files for Windows even though MSI is deprecated. 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. 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. 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. [1] https://hydraulic.dev/ https://hydraulic.dev/ [2] https://github.com/hydraulic-software/conveyor/issues/73 https://github.com/hydraulic-software/conveyor/issues/73
anonymouse008 3y ago
I'm going to ask a 'self-taught' question, so my terms may be incorrect. 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.
- willcipriano 3y ago
  Solved as in you don't have to do anything and it just works or solved as in there is a way to fix the problem but it requires some effort?
  - anonymouse008 3y ago
    Ha! Yeah I want the magic wand. I have deep wounds from pre-chatGPT times of trying to manually figure out libraries. As in otooling each library, error, etc then recompiling into various places until things 'worked.' I'm appreciative of the experience, though now I think with LLMs the problem could be solved with some simple queries. So I guess you're right, it requires effort, but I was a 10x engineer in the wrong direction and never want to experience that again ;)
    - willcipriano 3y ago
      What works for me is figuring out the platforms I need to support and creating a build pipeline that can handle those requirements. If you join onto a project I don't want you playing around with libraries on your local machine. If you are I consider that a failure of the build script/makefile/docker compose file/etc. First it's lost productivity, second you might get it wrong and have misleading results, causing more lost productivity. A lot of places do this nonsense "spend hours configuring your machine" method for projects. The only reason I can think of doing that is "job security" and who wants to keep a job with horrible tooling? But yeah, it takes effort to do.
      - anonymouse008 3y ago
yellowapple 3y ago
> 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. Why not?
- packetlost 3y ago
  Probably because it doesn't actually package the Python interpreter into the executable and relies on a hashbang (ie. `#!/bin/python`) to actually run the bundled source files. Pex [0] does the same thing. It's a half solution at best, but if you control the infrastructure it does dramatically simplify things like Dockerfiles and other deployment stuff. Not super useful for general distribution IMO. [0]: https://pex.readthedocs.io/en/v2.1.140/ https://pex.readthedocs.io/en/v2.1.140/
  - totetsu 3y ago
    I ran into ssh cypher issues when I tried to share a packed python project. Worked on my machine but not my colleagues
  - hackan 3y ago
    It's a cool trick, I used it to pack a tool long time ago: https://github.com/HacKanCuBa/passphrase-py/blob/219d6374338ed9a1475b4f09b0d85212376f11e0/Makefile#L40 https://github.com/HacKanCuBa/passphrase-py/blob/219d6374338... Basically, u zip the package, then add the shebang on the zip binary. Quite cool and simple! No need for external tools :p
  - yellowapple 3y ago
    That's a bummer. An app being self-contained is kinda the point of an AppImage IMO, and depending on an external Python (if one even exists) throws a wrench in that.
synergy20 3y ago
is this mainly for packaging python GUI programs cross-platform? how is it different from pyinstaller with tkinter?
40four 3y ago
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?
- gcanyon 3y ago
  This isn't intended as a dig at you, but in what world should an "Install Kivy" page take ~10 screens of text to display? If my goal is to build a simple Python app I can give to my friends and say, "here, I made this, give it a try," then that install page is screaming at me not to use Kivy to do that. https://kivy.org/doc/stable/gettingstarted/installation.html https://kivy.org/doc/stable/gettingstarted/installation.html
  - gcanyon 3y ago
    I'll add: the "getting started" collection of pages where I found that "install kivy" monstrosity then goes on to an "A first app" page, which...doesn't walk you through building your first app. Instead, it links to a page in a different collection of pages. And that page describes how to build a Pong app (too complex to be a "build my first app" -- there's a reason to start with "Hello World")...except it doesn't, it says that it assumes you already know how to create a Kivy application, and refers you to another page if you don't. And that page does "Hello World, but poorly.
    - gcanyon 3y ago
      Okay, one more and I'll shut up. The app is unsigned (on MacOS) so you can't double-click or command-O it -- you therefore have to right-click and select Open, and then acknowledge the dire warning about running unsigned code. I don't see any mention of this on the over-long install page, so anyone who doesn't know how to run unsigned code on a Mac is out of the game immediately. And after all that, the app doesn't run. So yeah. I put off learning python for years because of this ridiculousness. Finally I decided to just bite the bullet, because it just isn't getting any better.
doctorpangloss 3y ago
How do I turn a setuptools setup.py entrypoint into a standalone .exe for Windows users?
janalsncm 3y ago
This seems perfect for one of my projects.

182 points by generichuman 3y ago

nu11ptr 3y ago

How does this compare to PyInstaller or other packagers? What underlying tech does it use?

WillAdams 3y ago
The big difference is it uses "Toga" https://beeware.org/project/projects/libraries/toga/ https://beeware.org/project/projects/libraries/toga/ which uses native widgets and manages basic functionality such as where the "Quit" menu entry is automatically. Looking into this now --- it looks perfect for my needs, just hoping that there's a nice graphical tool for laying out a GUI (if it has a graphical programming mode like to Blockly or Ryven, then it is perfect for me).
- fock 3y ago
  so essentially what Kivy did already a bit ago.
  - nbadg 3y ago
    I haven't used Kivy in quite a while, so maybe this has changed, but as far as I know -- no, Kivy hasn't done something like this. In Kivy, everything looks like Kivy, regardless of what platform you're on, and you need to explicitly lay everything out, including whichever changes you want for a particular platform. Whereas with Toga, the UI is changed to match the user's expectations for that platform, automatically. One example of this, as parent mentioned, is where the "quit" button is located. Different platforms put this in different places. Toga will automatically put it in the right one, depending on which platform you're on. Buttons will look like normal buttons on a Mac, but also like normal buttons on Windows -- depending on which platform you're on.
    - dr_kiszonka 3y ago
      Hi! Do you know whether Kivy or Toga/BeeWare lets you access Android API? For example, I want my app to listen to BatteryManager's broadcasts [0]. Is it possible using any of these frameworks? (Or any other Python-centric framework?) I read that Toga supports background tasks, but it is not clear to me if I could use them to listen to Android broadcasts. 0. https://developer.android.com/training/monitoring-device-state/battery-monitoring https://developer.android.com/training/monitoring-device-sta...
      - WillAdams 3y ago
        They give an example of using Apple's Obj-C framework, so I believe this sort of thing is possible.
skinner927 3y ago
It appears PyInstaller is much more portable. Briefcase seems to make an .msi installer on Windows and an AppImage for Linux. Both of those require installation to use. PyInstaller can create a single executable that you can just run (yea sure it extracts itself to a temp dir, but the optics are very different).

mvdwoord 3y ago

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. https://www.youtube.com/watch?v=TY4vb6V-gvc https://www.youtube.com/watch?v=TY4vb6V-gvc

deleted 3y ago

[deleted]

velosol 3y ago

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.

mike_hearn 3y ago

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. There are many of these open source packagers and they all share very similar problems: 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). 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. 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. 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. 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. 6. They make MSI files for Windows even though MSI is deprecated. 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. 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. 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. [1] https://hydraulic.dev/ https://hydraulic.dev/ [2] https://github.com/hydraulic-software/conveyor/issues/73 https://github.com/hydraulic-software/conveyor/issues/73

anonymouse008 3y ago

I'm going to ask a 'self-taught' question, so my terms may be incorrect. 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.

willcipriano 3y ago
Solved as in you don't have to do anything and it just works or solved as in there is a way to fix the problem but it requires some effort?
- anonymouse008 3y ago
  Ha! Yeah I want the magic wand. I have deep wounds from pre-chatGPT times of trying to manually figure out libraries. As in otooling each library, error, etc then recompiling into various places until things 'worked.' I'm appreciative of the experience, though now I think with LLMs the problem could be solved with some simple queries. So I guess you're right, it requires effort, but I was a 10x engineer in the wrong direction and never want to experience that again ;)
  - willcipriano 3y ago
    What works for me is figuring out the platforms I need to support and creating a build pipeline that can handle those requirements. If you join onto a project I don't want you playing around with libraries on your local machine. If you are I consider that a failure of the build script/makefile/docker compose file/etc. First it's lost productivity, second you might get it wrong and have misleading results, causing more lost productivity. A lot of places do this nonsense "spend hours configuring your machine" method for projects. The only reason I can think of doing that is "job security" and who wants to keep a job with horrible tooling? But yeah, it takes effort to do.
    - anonymouse008 3y ago

yellowapple 3y ago

> 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. Why not?

packetlost 3y ago
Probably because it doesn't actually package the Python interpreter into the executable and relies on a hashbang (ie. `#!/bin/python`) to actually run the bundled source files. Pex [0] does the same thing. It's a half solution at best, but if you control the infrastructure it does dramatically simplify things like Dockerfiles and other deployment stuff. Not super useful for general distribution IMO. [0]: https://pex.readthedocs.io/en/v2.1.140/ https://pex.readthedocs.io/en/v2.1.140/
- totetsu 3y ago
  I ran into ssh cypher issues when I tried to share a packed python project. Worked on my machine but not my colleagues
- hackan 3y ago
  It's a cool trick, I used it to pack a tool long time ago: https://github.com/HacKanCuBa/passphrase-py/blob/219d6374338ed9a1475b4f09b0d85212376f11e0/Makefile#L40 https://github.com/HacKanCuBa/passphrase-py/blob/219d6374338... Basically, u zip the package, then add the shebang on the zip binary. Quite cool and simple! No need for external tools :p
- yellowapple 3y ago
  That's a bummer. An app being self-contained is kinda the point of an AppImage IMO, and depending on an external Python (if one even exists) throws a wrench in that.

synergy20 3y ago

is this mainly for packaging python GUI programs cross-platform? how is it different from pyinstaller with tkinter?

40four 3y ago

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?

gcanyon 3y ago
This isn't intended as a dig at you, but in what world should an "Install Kivy" page take ~10 screens of text to display? If my goal is to build a simple Python app I can give to my friends and say, "here, I made this, give it a try," then that install page is screaming at me not to use Kivy to do that. https://kivy.org/doc/stable/gettingstarted/installation.html https://kivy.org/doc/stable/gettingstarted/installation.html
- gcanyon 3y ago
  I'll add: the "getting started" collection of pages where I found that "install kivy" monstrosity then goes on to an "A first app" page, which...doesn't walk you through building your first app. Instead, it links to a page in a different collection of pages. And that page describes how to build a Pong app (too complex to be a "build my first app" -- there's a reason to start with "Hello World")...except it doesn't, it says that it assumes you already know how to create a Kivy application, and refers you to another page if you don't. And that page does "Hello World, but poorly.
  - gcanyon 3y ago
    Okay, one more and I'll shut up. The app is unsigned (on MacOS) so you can't double-click or command-O it -- you therefore have to right-click and select Open, and then acknowledge the dire warning about running unsigned code. I don't see any mention of this on the over-long install page, so anyone who doesn't know how to run unsigned code on a Mac is out of the game immediately. And after all that, the app doesn't run. So yeah. I put off learning python for years because of this ridiculousness. Finally I decided to just bite the bullet, because it just isn't getting any better.

doctorpangloss 3y ago

How do I turn a setuptools setup.py entrypoint into a standalone .exe for Windows users?

janalsncm 3y ago

This seems perfect for one of my projects.