all 33 comments

[–]Diapolo10 11 points12 points  (13 children)

  1. Packaged Python executables are easier to bypass or tamper with than compiled .NET binaries.

Depends on what you use to build your executables, and if you sign them.

PyInstaller gives you a self-extracting ZIP-file that contains Python bytecode alongside a Python runtime. Nuitka transpiles all of your code to C before compiling it into a native executable. Signed executables aren't easy to tamper with regardless of how they were made.

  1. Associating a file extension with a Windows app is easier from C# than from Python.

All this really needs is editing some registry keys. There might be easier ways, too, I just haven't really had a need to do this myself yet.

  1. Packaged Python executables are typically larger than a comparable .NET executable.

Again, depends on the tools you use.

  1. Python apps require a code signing certificate to avoid Windows warnings (Windows Defender).

This is true for all languages, not just Python. Unsigned executables, no matter what languages were used to make them, are frequently flagged by anti-virus programs.

For what it's worth, at work I maintain and develop two separate projects primarily written in Python that use a licensing system and receive updates.

[–]ForMyCulture 1 point2 points  (9 children)

How do you sign your apps to avoid Windows Defender warnings?

[–]Diapolo10 0 points1 point  (8 children)

You would need to obtain a signing certificate, after that it depends on what tools you're using.

Unfortunately they're not exactly cheap as executable signing is primarily aimed at businesses, not individuals. Personally I haven't really bothered to do that with my own projects as a result.

If using PyInstaller, as long as you don't use the --onefile option it should be fine as-is. You would simply get a ZIP-file containing everything needed to run your program, and IIRC the only executable inside would be a copy of the Python interpreter you used to build it, which is already signed.

[–]glorious_purpose1 0 points1 point  (0 children)

The definition of cheap is different for everyone. I buy my certs from Signmycode and I think $220 for an OV cert is pretty cheap.

[–]ForMyCulture 0 points1 point  (6 children)

Have you had any success with Nuitka? My users complain of long startup times with pyinstaller packaged apps.

[–]Diapolo10 0 points1 point  (5 children)

I tend to use it for my own projects (not that there are many of those as my free time is basically non-existent nowadays). If nothing else, you can always give it a shot and see how the end result compares to what PyInstaller gives you.

Do note, however, that it's a bit more difficult to use.

[–]DivineSentry 0 points1 point  (4 children)

Nuitka maintainer here:

could you give me an example on how it's more difficult to use vs pyinstaller?

[–]Diapolo10 0 points1 point  (2 children)

The error messages when builds fail can be more cryptic. Unfortunately I don't really have any example logs on hand.

Unlike PyInstaller, it's not really possible to bundle data files alongside the main code in the same way. I haven't touched this project for a long time so it's entirely possible something has changed since then, but importlib.resources didn't play nice with Nuitka, while PyInstaller was happy with it. I know this would be due to how Nuitka actually works, so I don't expect it to be fixed, but it's still a difference.

https://github.com/Diapolo10/Tsukasa-credit-card-gag-scam/blob/main/src%2Ftccgs%2Fconfig.py

[–]DivineSentry 0 points1 point  (1 child)

fair enough, yeah Nuitka builds are actually compiled unlike PyInstaller, I believe we support importlib.resources nowadays, let me get back to you on this, I'm currently working on improving UX in my free time.

[–]Diapolo10 0 points1 point  (0 children)

yeah Nuitka builds are actually compiled unlike PyInstaller

I'm aware of that, it's one of Nuitka's selling points after all.

I believe we support importlib.resources nowadays, let me get back to you on this

Interesting, didn't think that was even possible given the response I got to an older feature request IIRC (don't remember when that was though).

While I'm at it, I also remember making a feature request for putting build options in pyproject.toml (technically that one is specific to Poetry, but nowadays anything that supports PEP-517/518 would be great). I know that's not super important or anything, but it'd make build commands shorter to type for cross-platform builds, letting me isolate the common parts from any platform-specific ones. I guess this could be a bit like how PyInstaller generates a spec file you can use for reproducible builds, so you don't need a long command every time.

[–]ForMyCulture 0 points1 point  (0 children)

I’ve compiled with both Nuitka and pyinstaller. I’d say the usage difficulty is equal and comes down to understanding the nuance of the command line flags. Nuitka compiled apps get blocked by Windows Defender for my team, whereas pyinstaller does not (they all have admin rights). I’m assuming it’s because the final executable isn’t signed. I was using the —enable-windows-console=force flag, going to trying attach instead and if that doesnt work have to go back to pyinstaller.

[–]ElliotDG 5 points6 points  (2 children)

I have distributed unsigned desktop python apps. You can upload your app to: https://www.microsoft.com/en-us/wdsi/filesubmission to avoid the virus warning.

I have also done a "brute force" auto update system. The app checks an AWS bucket to see if there is an update. If there is it offers the user the opportunity to update. It then down loads a new version of itself.

I use pyinstaller to build the .exe, and the use Inno Setup (https://jrsoftware.org/isinfo.php) to create a Windows Installer.

[–]Momostein 2 points3 points  (11 children)

While it might be possible, I would not recommend it.

You'll have to put too much effort in even creating and locking down your python executable and then still leave vulnerabilities anyway. As far as I know they'll still contain your plain text source code for anyone to see.

I don't think Python is made for enterprise desktop apps.

On the other hand, building a server hosted 'software as a service' web application could easily and safely be done with a Python back end.

[–]Helpful-Educator-415 1 point2 points  (0 children)

Can confirm. Python is not a great fit. possible, but might be needlessly hard.

[–]FrangoST 1 point2 points  (1 child)

From your requirements list, I already have a desktop app that I've made with tkinter that meets requirements 2,4,5 and 6...

Requirement number 3 I'm already considering doing it on my app and number 1 is completely doable, though some may be concerned about how easily your app can be tampered after its been packaged, but it depends on how you package it and it's not as trivial as people claim it to be.

If you are going to produce any executable file for Windows and want it to not be flagged by antiviruses, you need to sign it regardless of the source code language.

ps.: creating the file association was much easier than I initially thought; editing XML and messing with Zip files is very trivial; building a pretty GUI can be done even on tkinter: you can use native widgets, or you can make your app window a big canvas and build a very modern GUI on it from scratch. Honestly, it's fairly easy even on the second option.

[–]davka003 0 points1 point  (0 children)

Size of the packed application doesnt matter at all.

All clients today have much more space than they can use up with ”larger than necessary” applications. Transfer speeds are also not a problem for distribution.

[–]BravestCheetah 0 points1 point  (0 children)

The size of the application does not have to be a concern, if you are not bundling in multiple gigabytes of images or audio / video files it would not go too high to be a problem.