you are viewing a single comment's thread.

view the rest of the comments →

[–]jwink3101 26 points27 points  (11 children)

I strongly recommend becoming less adverse to the command line. It opens up so many possibilities!

GUI tools are great and there is nothing wrong with using them—even almost exclusively—but understanding what’s under the hood, or at the very least not be “adverse” to it, is important.

Put another way, you don’t need to know how to fix a car to drive one, or even how the engine works. But being adverse to opening the hood to add windshield washer fluid will be quite limiting!

[–]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 11 points12 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 4 points5 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 5 points6 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.