On Sat, Jul 11, 2015 at 7:51 PM, Ulli Horlacher <frams...@rus.uni-stuttgart.de> wrote: > Chris Angelico <ros...@gmail.com> wrote: > >> On Sat, Jul 11, 2015 at 7:28 PM, Ulli Horlacher >> <frams...@rus.uni-stuttgart.de> wrote: >> > I want to start a project with python. >> > The program must have a (simple) GUI and must run on Linux and Windows. >> > The last one as standalone executable, created with pyinstaller. >> >> Not sure what your advantage is with pyinstaller, it adds a level of >> complication that doesn't usually justify itself IMO. > > I am not addicted to pyinstaller. It just works. > Do you have a better alternative? > > >> Using wxPython means you need another library, while tkinter comes >> with Python. > > pyinstaller can make a standalone executable, there is no need for the > users to install "another library". They just click on the program icon, > that's it.
Yeah, I'd distribute the .py files and have done with it. Maybe do it up as a package and distribute it via pip, which allows you to fetch dependencies automatically. The supposed ease of "just click on the program icon" is all very well, but it means you have to have a whopping new download any time there's an update to your code (they have to redownload the entire binary even if you're using the same Python and the same libraries), and you have to distribute a whole bunch of different versions (32-bit vs 64-bit, possibly different builds for different Windowses, etc), and deal with the support issues from people who grabbed the wrong one. Once Python itself has been installed, users can still normally "just click on the program icon" even though it's a .py file - that's the whole point of file associations. And then their installed Python can be updated by the normal mechanisms, and your code will happily run on the new version. Suppose, for instance, that your program does something over HTTPS, and people are using it in a critical environment... and then someone discovers a flaw in OpenSSL, which has happened now and then. A bugfix release of CPython will fix that instantly for everyone who's using the standard python.org downloads; but if you've packaged up your own Python, it'll be frozen at whatever version you had when you built that - which might not even be the latest available at the time. How quickly will you get around to building new installers? Much better to distribute Python code without an interpreter, and let people get their own interpreters. ChrisA -- https://mail.python.org/mailman/listinfo/python-list