Jonathan Hartley wrote: > While examining py2exe et al of late, my thoughts keep returning to > the idea of writing, in C or similar, a compiled stand-alone > executable 'bootstrapper', which: > 1) downloads and install a Python interpreter if none exists > 2) runs the application's Python source code using this interpreter. > > An application source code could be distributed with this small exe to > wrap its top level 'main.py', and the application could then be run on > machines which do not (yet) have Python installed. > > The goal of this is to provide a way for end-users to download and > double-click a Python application, without having to know what Python > is or whether (an appropriate version of) it is installed. This method > has some disadvantages compared to using py2exe et al, but it has the > advantage that a small application would remain small: there is no > need to bundle a whole interpreter with every application.
There are two major issues with such an approach: * users will not necessarily like it if a small application downloads a several MB from the web somewhere without asking * installing applications on Windows typically requires admin rights or at least user interaction I think a good solution to the problem is wrapping the application's main.py in a batch file which pops up a window to let the user know that s/he will need to install Python first and point him/her to the www.python.org web site, if necessary. Another aspect to consider is whether a py2exe wrapped Python application is really too big at all. We ship a rather complex application using py2exe (mxODBC Connect Server) and the resulting installed footprint is just around 14 MB - that's roughly the size of a typical YouTube video. By comparison, a full Python 2.5 installation is around 84 MB and includes lots of stuff normally not needed for a small Python application. > From an > advocacy point of view, it also must help that merely running such an > application would seamlessly put a usable Python interpreter installed > and on the PATH on Windows boxes. > > Even my very limited understanding of the issues is enough to see that > the idea is far from trivial. I'm aware that great minds are working > on related and overlapping problems, so I thought I'd ask whether many > people have done this already, and if not, is there any value in > taking the trivial first step described above? ie. Ignore all > complications, and write a simple C program to download & install an > interpreter, then use that to run my Python. > > In the long run, to be useful for real projects, the bootstrapper > would need to manage some nasty details: > * different versions of the interpreter for different applications > * download required packages > * manage conflicting versions of packages > I'm hoping that these thorny problems will be solved, if they aren't > already, by the great minds working on packaging, etc. > > I'm very aware that I don't know anything at all about this, compared > to many on the list. Be gentle with me. :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 13 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- http://mail.python.org/mailman/listinfo/python-list
