On 10 July 2013 05:49, CM <cmpyt...@gmail.com> wrote: > On Wednesday, July 10, 2013 12:12:16 AM UTC-4, Joshua Landau wrote: >> On <some multitude of times>, CM <cmpyt...@gmail.com> wrote: >> >> > What I was thinking of was that if you are going to sell software, you >> > want to make it as easy as possible, and that includes not making the >> > potential customer have to install anything, or even agree to allow you to >> > "explicitly" install a runtime on their computer. If the potential >> > customer just sees, clicks, and installs, that should be the most they >> > ought to have to do. > >> I don't really get what you are saying. Do you, or do you not, want it >> installed? > > I'm just saying that sometimes one goes to download new software and are met > with a statement such as: > > "Installing Eclipse is relatively easy, but does involve a few steps and > software from at least two different sources. Eclipse is a Java-based > application and, as such, requires a Java runtime environment (JRE) in order > to run. ...Regardless of your operating system, you will need to install some > Java virtual machine (JVM). You may either install a Java Runtime Environment > (JRE), or a Java Development Kit (JDK), depending on what you want to do with > Eclipse." > > This is not always the type of thing you want your customers to encounter. > > Can all the installation of the runtimes be done with an installer that is > itself an .exe, like with PyInstaller? If so, that's probably fine.
I don't get what PyInstaller has to do with that, it seems to do something other than what you said. The rest of my naïve just-thought-of-it-now approach is below. >> > Maybe. I'll have to think about it. I'm referring to libaries as >> > dependencies. So for example, though .py files are small, wxPython, for >> > example, isn't tiny, nor are other libraries one might use. >> >> Please excuse the fact I haven't done anything serious on Windows in >> years so I'm not really sure what I'm saying. How does Windows deal >> with dependencies? >> >> It's going to have to be fetched at one point anyway, so that's either >> at download-time, install-time or run-time. The first lets you just >> add it to the archive, the second lets you deal with it through a good >> standard distribution manager thing, the third is potentially crazy. >> Hence, wutz za probem bruv? > > I'm good with the first way, and I'm fine with Linux's package > manager/whatever doing it the second. For the second I meant something like setuptools, distribute, distutils and co. > To simplify everything: sales require massive simplicity for (some) end > users. You can get 1-2 clicks out of them before they drop dead as buyers. I was mainly talking in the context of the original post, where it seems something slightly different was meant. If you're deploying to customers, you'd want to offer them an installer. At least, I think you would. That's different from packing Python into a .exe file and pretending it's good-to-go. If they don't want it installed, again the best thing to do is an archive with some "executable" (possibly a batch file or something -- you Windows people would know better what you need) that just runs "python main_file.py". Then get them to extract + click. That's 2 operations, and a lot faster than some silly install process. That does require them to install Python, but you can just add Python's installer in there. That makes 3 operations, but you can always make the "launcher" run the installer if it's not found. >Furthermore, and I haven't mentioned this yet, an .exe file on Windows has the >look of authenticity, whereas a .py file (which is a text file, really) >doesn't, which might also matter to customer perceptions. This is all >psychology. Unfortunately I cannot argue with that stupidity. It's true but shameful. > The ease of deployment side is up for grabs, but yes, potentially a hassle > for cross platform deployment. > > I'm open to the idea of using an installer .exe to set up the user's computer > with Python and all the libraries he needs to get going. I just haven't done > that so far. There are a lot of ways of making an installer, and my current few Googles have shown that distutils comes with a way of making .msi files¹, and there's also http://wix.tramontana.co.hu/. Some random internet guy reccomended https://code.google.com/p/omaha/, but I've no idea if it's appropriate. There's also http://nsis.sourceforge.net/Main_Page. Again, I'm no Windows user so I'm talking by guessing. These are saner solutions because they focus on installing rather than pretending that a .exe file with a packaged Python is anything like a compiled C source. ¹ Just run "python setup.py bdist_msi" with a working setup.py and you get a free .msi! I don't know what the .msi assumes, and I have no way of testing as of now. -- http://mail.python.org/mailman/listinfo/python-list
