Columns represent methods of deploying to end-users such that they don't have to worry about installing Python, packages or other dependencies. 'Bundle' represents manually bundling an interpreter with your app. 'Bootstrap' represents a fanciful idea of mine to include an installer that downloads and installs an interpreter if necessary. This sounds fiddly, since it would have to install side-by- side with any existing interpreters of the wrong version, without breaking anything. Has anyone done this?
The remaining columns represent the projects out there I could find which would do the bundling for me.
Are there major things I'm missing or misunderstanding?
Perhaps folks on the list would care to rate (+1/-1) rows that they find important or unimportant, or suggest additional rows that would be important to them. Maybe an updated and complete version of this table would help people agree on what's important, and help the various projects to improve faster.
> Columns represent methods of deploying to end-users such that they > don't have to worry about installing Python, packages or other > dependencies. 'Bundle' represents manually bundling an interpreter > with your app. 'Bootstrap' represents a fanciful idea of mine to > include an installer that downloads and installs an interpreter if > necessary. This sounds fiddly, since it would have to install side-by- > side with any existing interpreters of the wrong version, without > breaking anything. Has anyone done this?
Maybe there is a way to use Portable Python for this, but I have no experience with it.
> The remaining columns represent the projects out there I could find > which would do the bundling for me.
> Are there major things I'm missing or misunderstanding?
> Perhaps folks on the list would care to rate (+1/-1) rows that they > find important or unimportant, or suggest additional rows that would > be important to them. Maybe an updated and complete version of this > table would help people agree on what's important, and help the > various projects to improve faster.
> Best regards,
> Jonathan
Good work. Recently I played with cx_freeze and compared it to py2exe, which I've been using for a while. Here are my findings:
1. I don't think cx_freeze supports single exe. I haven't even been able to get it to append the generated library.zip file to the executable using documented options. Other things like .pyd files always seem to be separate. At the same time, singe executables generated by py2exe do not always work. I have a program that works fine on Windows XP, Vista, and 7 if it is built under XP. However, if I build the exact same program under Windows 7, it no longer works on Vista or XP. I'm sure it has something to do with SxS or other dll issues.
2. For output directory structure, you are able to specify where to put the generated executable and all of its dependencies with both py2exe and cx_freeze. You cannot do things like put python26.dll in a separate directory from the executable. Not sure if that is what you are referring to.
3. py2exe does not support Python 3 (unfortunately).
4. Although cx_freeze does support optimization (-O), it's a bit broken in that the __debug__ variable is always set to True. In other words, the code is optimized and things like assert statements are not executed, but conditional statements that check __debug__ == True are. I know that py2exe does not have this problem, no experience with other tools.
5. py2exe is capable of generating smaller executables than cx_freeze because of the base executable size (18.5 KB vs 1.35 MB). This is offset by the fact that py2exe saves many more standard library components to library.zip by default. In a quick test I just ran, both generated a package of 4.03 MB, but I can remove at least a meg from py2exe's library.zip. Rather than "distribution size", I think it makes more sense to show "overhead" above the required components (exclude minimal library.zip, python dll, and pyd files).
6. cx_freeze is as easy to use as py2exe after looking at the bundled examples.
> Columns represent methods of deploying to end-users such that they > don't have to worry about installing Python, packages or other > dependencies. 'Bundle' represents manually bundling an interpreter > with your app. 'Bootstrap' represents a fanciful idea of mine to > include an installer that downloads and installs an interpreter if > necessary. This sounds fiddly, since it would have to install side-by- > side with any existing interpreters of the wrong version, without > breaking anything. Has anyone done this?
> The remaining columns represent the projects out there I could find > which would do the bundling for me.
> Are there major things I'm missing or misunderstanding?
> Perhaps folks on the list would care to rate (+1/-1) rows that they > find important or unimportant, or suggest additional rows that would > be important to them. Maybe an updated and complete version of this > table would help people agree on what's important, and help the > various projects to improve faster.
> Best regards,
> Jonathan
Another thing that I think is of interest is whether the application support modifying the version and description of the exe (that is, on Windows, when you right-click on an application and choose 'properties' you view the version number and description of the application, it is a resource inside the exe). I think py2exe supports it.
>> Columns represent methods of deploying to end-users such that they >> don't have to worry about installing Python, packages or other >> dependencies. 'Bundle' represents manually bundling an interpreter >> with your app. 'Bootstrap' represents a fanciful idea of mine to >> include an installer that downloads and installs an interpreter if >> necessary. This sounds fiddly, since it would have to install side-by- >> side with any existing interpreters of the wrong version, without >> breaking anything. Has anyone done this?
>> The remaining columns represent the projects out there I could find >> which would do the bundling for me.
>> Are there major things I'm missing or misunderstanding?
>> Perhaps folks on the list would care to rate (+1/-1) rows that they >> find important or unimportant, or suggest additional rows that would >> be important to them. Maybe an updated and complete version of this >> table would help people agree on what's important, and help the >> various projects to improve faster.
>> Best regards,
>> Jonathan
> Another thing that I think is of interest is whether the application > support modifying the version and description of the exe (that is, on > Windows, when you right-click on an application and choose > 'properties' you view the version number and description of the > application, it is a resource inside the exe). I think py2exe supports > it.
> 1. I don't think cx_freeze supports single exe. I haven't even been > able to get it to append the generated library.zip file to the > executable using documented options. Other things like .pyd files > always seem to be separate. At the same time, singe executables > generated by py2exe do not always work. I have a program that works > fine on Windows XP, Vista, and 7 if it is built under XP. However, if > I build the exact same program under Windows 7, it no longer works on > Vista or XP. I'm sure it has something to do with SxS or other dll > issues.
I had similar issues with under Vista generated programs not running under 2K (unfortunately I have to support it). This behavior came from the .dll dependency tracking of py2exe, which included a OS .dll into the dist output.
These are the steps I toke to find the offending .dll * generated a "flat" directory (the .dll's not packed into library.zip) with options = { [...], 'bundle_files': 3 } * extracted the not loadable extension from library.zip * examined the dependencies of this module with Microsoft's "Dependency Walker" (you can find it somewhere in the MSDN) * added the superfluous .dll to the options = { [...], 'dll_excludes': ['offending.dll'] } parameter
iu2 wrote: > Another thing that I think is of interest is whether the application > support modifying the version and description of the exe (that is, on > Windows, when you right-click on an application and choose > 'properties' you view the version number and description of the > application, it is a resource inside the exe). I think py2exe supports > it.
On Nov 4, 11:21 am, Vesa Köppä <vesa.ko...@gmail.com> wrote:
> iu2 wrote: > > Another thing that I think is of interest is whether the application > > support modifying the version and description of the exe (that is, on > > Windows, when you right-click on an application and choose > > 'properties' you view the version number and description of the > > application, it is a resource inside the exe). I think py2exe supports > > it.
> Pyinstaller supports this.
> Vesa
Thanks all for the inputs. I've updated my little chart and will continue to refine and fill in the blanks.
I noticed information on py2app was mostly missing from your chart.
--single exe file: yes, with qualification. On the Mac, standalone applications are actually directories called "application bundles" designed to look like a single file that can be double-clicked on. So, a lot of stuff--the Python libraries, icons, other resource files--are hidden inside the app bundle.
--without unzipping at runtime--Yes. --control over output directory structure--no.
--creates installer too: yes, with qualification. If you're building an app, you don't use an installer--the standard Mac method is drag-and-drop installation. You can also use py2app to package up Python libraries, and for these, it can create a standard Mac pkg installer.
--Python 3--not yet, as far as I know. --can run as -O--not sure. --control over process/ouput--not sure what this means. --distribution size--Varies widely. A big Python application with lots of libraries can exceed 100 megabytes, easily. A Python/Tkinter app with no other extensions would weigh in at about 20 megabytes--that's the smallest. --active development--some, but only in svn. Last stable release was a few years ago. --active mailing list--no standalone mailing list, but the PythonMac-sig mailing list has lots of discussion and bug reporting on py2app.
> If you don't want to spend time marking the table up, I'm sure I could > help you out.
> Paul
Nice idea Paul, and thanks for the offer. I'll ping you for guidance at least, as and when I reckon I've got the table into half decent shape. I notice the wiki page you linked to contains a bunch of options and information I wasn't even aware of, so I've probably got some work to do before that happens.
Hey Marco. Thanks for the heads-up. It's suppose to be a link to a shared google docs spreadsheet. At least some other people are able to see it without problems. If you're keen to see it, and it remains non- functional for you, and you're willing to help me try and debug this, then email me off list and maybe we could try some alternative ways of publishing it. Do you happen to know if other google docs spreadsheets work for you?
> I noticed information on py2app was mostly missing from your chart.
> --single exe file: yes, with qualification. On the Mac, standalone > applications are actually directories called "application bundles" > designed to look like a single file that can be double-clicked on. So, a > lot of stuff--the Python libraries, icons, other resource files--are > hidden inside the app bundle.
> --without unzipping at runtime--Yes. > --control over output directory structure--no.
> --creates installer too: yes, with qualification. If you're building an > app, you don't use an installer--the standard Mac method is > drag-and-drop installation. You can also use py2app to package up Python > libraries, and for these, it can create a standard Mac pkg installer.
> --Python 3--not yet, as far as I know. > --can run as -O--not sure. > --control over process/ouput--not sure what this means. > --distribution size--Varies widely. A big Python application with lots > of libraries can exceed 100 megabytes, easily. A Python/Tkinter app with > no other extensions would weigh in at about 20 megabytes--that's the > smallest. > --active development--some, but only in svn. Last stable release was a > few years ago. > --active mailing list--no standalone mailing list, but the PythonMac-sig > mailing list has lots of discussion and bug reporting on py2app.
Thanks heaps Kevin - I don't have a Mac, so I was just inferring information about py2app. Although my app does run on Macs and one of my Mac-loving friends has kindly agreed to help me produce Mac binaries, so this information is brilliant to know. Many thanks!
> I noticed information on py2app was mostly missing from your chart.
> --single exe file: yes, with qualification. On the Mac, standalone > applications are actually directories called "application bundles" > designed to look like a single file that can be double-clicked on. So, a > lot of stuff--the Python libraries, icons, other resource files--are > hidden inside the app bundle.
> --without unzipping at runtime--Yes. > --control over output directory structure--no.
> --creates installer too: yes, with qualification. If you're building an > app, you don't use an installer--the standard Mac method is > drag-and-drop installation. You can also use py2app to package up Python > libraries, and for these, it can create a standard Mac pkg installer.
> --Python 3--not yet, as far as I know. > --can run as -O--not sure. > --control over process/ouput--not sure what this means. > --distribution size--Varies widely. A big Python application with lots > of libraries can exceed 100 megabytes, easily. A Python/Tkinter app with > no other extensions would weigh in at about 20 megabytes--that's the > smallest. > --active development--some, but only in svn. Last stable release was a > few years ago. > --active mailing list--no standalone mailing list, but the PythonMac-sig > mailing list has lots of discussion and bug reporting on py2app.
You are right that my 'control over process/output' is not at all clear. I shall think about what actual goal I'm trying to achieve with this, and re-describe it in those terms.
Plus, as others have suggested, my guesstimate of 'distribution size' would probably be more usefully described as 'size overhead', ie. how big would the distribution be for a one-line python console 'hello world' script. I hope to try it out and see.
Hi Jonathan, I'm asking similar questions for the app suite that we're developing on my current project, so I thank you for doing my work for me. ;)
I was interested in py2exe because we'd like to provide a one download, one click install experience for our Windows users. I think a lot of people are interested in py2exe for the same reason. Well, one thing that I came across in my travels was the fact that distutils can create MSIs. Like py2exe, MSIs provide a one download, one click install experience under Windows and therefore might be a replacement for py2exe.
For me, the following command was sufficient to create an msi, although it only worked under Windows (not under Linux or OS X): python setup.py bdist_msi
The resulting MSI worked just fine in my extensive testing (read: I tried it on one machine).
It seems, then, that creating an MSI is even within the reach of someone like me who spends very little time in Windows-land, so it might be worth a column on your chart alongside rpm/deb.
> I was interested in py2exe because we'd like to provide a one download, > one click install experience for our Windows users. I think a lot of > people are interested in py2exe for the same reason. Well, one thing > that I came across in my travels was the fact that distutils can create > MSIs. Like py2exe, MSIs provide a one download, one click install > experience under Windows and therefore might be a replacement for py2exe.
But py2exe and .msi are complementary, not a replacement. py2exe collects in one directory (or even in one file in some cases) all the pieces necesary to run your application. That is, Python itself + your application code + all referenced libraries + other required pieces. The resulting files must be installed in the client machine; you either build a .msi file (a database for the Microsoft Installer) or use any other installer (like InnoSetup, the one I like).
> For me, the following command was sufficient to create an msi, although > it only worked under Windows (not under Linux or OS X): > python setup.py bdist_msi
> The resulting MSI worked just fine in my extensive testing (read: I > tried it on one machine).
The resulting .msi file requires Python already installed on the target machine, if I'm not mistaken. The whole point of py2exe is to avoid requiring a previous Python install.
> It seems, then, that creating an MSI is even within the reach of someone > like me who spends very little time in Windows-land, so it might be > worth a column on your chart alongside rpm/deb.
>> I was interested in py2exe because we'd like to provide a one >> download, one click install experience for our Windows users. I >> think a lot of people are interested in py2exe for the same reason. >> Well, one thing that I came across in my travels was the fact that >> distutils can create MSIs. Like py2exe, MSIs provide a one >> download, one click install experience under Windows and therefore >> might be a replacement for py2exe.
> But py2exe and .msi are complementary, not a replacement. > py2exe collects in one directory (or even in one file in some cases) > all the pieces necesary to run your application. That is, Python > itself + your application code + all referenced libraries + other > required pieces. > The resulting files must be installed in the client machine; you > either build a .msi file (a database for the Microsoft Installer) or > use any other installer (like InnoSetup, the one I like).
>> For me, the following command was sufficient to create an msi, >> although it only worked under Windows (not under Linux or OS X): >> python setup.py bdist_msi
>> The resulting MSI worked just fine in my extensive testing (read: I >> tried it on one machine).
> The resulting .msi file requires Python already installed on the > target machine, if I'm not mistaken. The whole point of py2exe is to > avoid requiring a previous Python install.
You're right; the MSI I created doesn't include prerequisites. It packaged up our app, that's it. To be fair to MSIs, they might be capable of including prerequisites, the app, and the kitchen sink. But I don't think Python's creation process through distutils makes that possible.
That's why I suggested MSIs belong alongside RPM/DEB in the chart (if they're to be included at all).
I wouldn't say that the whole point of py2exe is to bundle Python. That's certainly a big benefit, but another benefit is that it can bundle an app into a one-click download. That's why we were interested in it.
>> It seems, then, that creating an MSI is even within the reach of >> someone like me who spends very little time in Windows-land, so it >> might be worth a column on your chart alongside rpm/deb.
py2exe looks great, but it remains to be seen if it's the easiest way to solve our problem. The MSI isn't nearly as nice for the end user, but we created it using only the Python standard library and our existing setup.py. Simplicity has value.
> On Nov 9, 2009, at 9:16 PM, Gabriel Genellina wrote:
> > En Fri, 06 Nov 2009 17:00:17 -0300, Philip Semanchuk <phi...@semanchuk.com > > > escribió: > >> On Nov 3, 2009, at 10:58 AM, Jonathan Hartley wrote:
> >>> Recently I put together this incomplete comparison chart in an > >>> attempt > >>> to choose between the different alternatives to py2exe:
> >> I was interested in py2exe because we'd like to provide a one > >> download, one click install experience for our Windows users. I > >> think a lot of people are interested in py2exe for the same reason. > >> Well, one thing that I came across in my travels was the fact that > >> distutils can create MSIs. Like py2exe, MSIs provide a one > >> download, one click install experience under Windows and therefore > >> might be a replacement for py2exe.
> > But py2exe and .msi are complementary, not a replacement. > > py2exe collects in onedirectory(or even in one file in some cases) > > all the pieces necesary to run your application. That is,Python > > itself + your application code + all referenced libraries + other > > required pieces. > > The resulting files must beinstalledin the client machine; you > > either build a .msi file (a database for the Microsoft Installer) or > > use any other installer (like InnoSetup, the one I like).
> >> For me, the following command was sufficient to create an msi, > >> although it only worked under Windows (not under Linux or OS X): > >>pythonsetup.py bdist_msi
> >> The resulting MSI worked just fine in my extensive testing (read: I > >> tried it on one machine).
> > The resulting .msi file requiresPythonalreadyinstalledon the > > target machine, if I'm not mistaken. The whole point of py2exe is to > > avoid requiring a previousPythoninstall.
> You're right; the MSI I created doesn't include prerequisites. It > packaged up our app, that's it. To be fair to MSIs, they might be > capable of including prerequisites, the app, and the kitchen sink. But > I don't thinkPython'screation process through distutils makes that > possible.
> That's why I suggested MSIs belong alongside RPM/DEB in the chart (if > they're to be included at all).
> I wouldn't say that the whole point of py2exe is to bundlePython. > That's certainly a big benefit, but another benefit is that it can > bundle an app into a one-click download. That's why we were interested > in it.
> >> It seems, then, that creating an MSI is even within the reach of > >> someone like me who spends very little time in Windows-land, so it > >> might be worth a column on your chart alongside rpm/deb.
> py2exe looks great, but it remains to be seen if it's the easiest way > to solve our problem. The MSI isn't nearly as nice for the end user, > but we created it using only thePythonstandard library and our > existing setup.py. Simplicity has value.
> Cheers > Philip
Hey Philip and Gabriel, Interesting to hear your respective perspectives - you've given me much to ponder and to read about. Personally I'm keen to find a method that doesn't require the end-user to have to manually install (the correct version of) Python separately from my app, so I think that rules out the distutils-generated MSI for me. I can see it has value for others though.
|
