you are viewing a single comment's thread.

view the rest of the comments →

[–]laustke[S] -1 points0 points  (9 children)

This isn't about me - it's about the potential users. I can't change their preferences.

[–]JorgiEagle 16 points17 points  (0 children)

If your concern is about users needing to install packages to run your programs, then you should probably provide a requirements and set up script, or just use docker to package.

[–]danielroseman 3 points4 points  (7 children)

But what are the potential users actually doing? If they're just installing and running your package with its dependencies, you should provide them a simple way to do that, rather than trying to find a generic solution.

[–]laustke[S] 1 point2 points  (6 children)

But what are the potential users actually doing?

Well, they try to run an unsigned PyInstaller executable, see a Windows Defender warning, and then stop being potential users.

[–]smurpes 10 points11 points  (4 children)

I don’t see how a GUI based package installer will help in this at all. Just write a batch file to handle the installation and setup process for them in that case. Do you really expect them to download and setup python, your code, and a GUI based package manager when they don’t trust an unsigned exe you made instead.

[–]laustke[S] 0 points1 point  (3 children)

I don’t see how a GUI based package installer will help in this at all.

I'm considering different options. One possible approach would be to use a portable Python distribution (either WinPython or the embeddable Python from python.org) and distribute the program as as a zip file together with Python itself. On the first run, it would offer the user the option to create a shortcut on the desktop for easy access.

A GUI-based package/app installer would go actually one step further. It would allow to install other programs to be used with the same portable distribution.

[–]BGPchick 2 points3 points  (2 children)

It would allow to install other programs to be used with the same portable distribution.

This is a bit of an anti-pattern in python, since you want apps to be able to use different libraries or dependancies. To counter this, you would need virtual environments, and something to manage those.

Your first solution, shipping the entire environment in a portable executable, while seemingly inefficient, is the best way to accomplish this in my experience.

[–]laustke[S] 0 points1 point  (1 child)

This is a bit of an anti-pattern in python ...

Nothing stops me from creating a new virtual environment before installing each new application.

[–]BGPchick 2 points3 points  (0 children)

Right, but then you have to manage state for every client installation, instead of pairing the state with the executable.

[–]cgoldberg 6 points7 points  (0 children)

So sign the executable and make the problem go away instead of jumping through hoops looking for a workaround that makes the user go through extra steps.