Re: comparing alternatives to py2exe
I found this: https://pypi.python.org/pypi/py2exe/0.9.2.0 Also, thanks for the spreadsheet, it's very useful. -- https://mail.python.org/mailman/listinfo/python-list
Re: comparing alternatives to py2exe
On Nov 10, 1:34 pm, Philip Semanchuk phi...@semanchuk.com wrote: 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: http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdgoutput... 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. As said inhttp://wiki.python.org/moin/DistributionUtilitiesthe easiest way is to use py2exe + InnoSetup. Easiest for you. =) The list of packages and modules that might require special treatment is almost a perfect superset of the modules we're using in our application:http://www.py2exe.org/index.cgi/WorkingWithVariousPackagesAndModules 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: comparing alternatives to py2exe
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: http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdgoutput=html 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. As said in http://wiki.python.org/moin/DistributionUtilities the easiest way is to use py2exe + InnoSetup. Easiest for you. =) The list of packages and modules that might require special treatment is almost a perfect superset of the modules we're using in our application: http://www.py2exe.org/index.cgi/WorkingWithVariousPackagesAndModules 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. Cheers Philip -- http://mail.python.org/mailman/listinfo/python-list
Re: comparing alternatives to py2exe
Maxim Khitrov schrieb:
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
HTH
Rudi
--
http://mail.python.org/mailman/listinfo/python-list
Re: comparing alternatives to py2exe
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: comparing alternatives to py2exe
Hi, in this discussion I read that we con create a bundle executable for our application, since I'm having troubles with create a exe due problems with kinterbasdb, can you show me tutorials for creating exe from bundle. thanks in advance. On Wed, Nov 4, 2009 at 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 -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
comparing alternatives to py2exe
Hi, Recently I put together this incomplete comparison chart in an attempt to choose between the different alternatives to py2exe: http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdgoutput=html 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: comparing alternatives to py2exe
On Tue, Nov 3, 2009 at 10:58 AM, Jonathan Hartley tart...@tartley.com wrote: Hi, Recently I put together this incomplete comparison chart in an attempt to choose between the different alternatives to py2exe: http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdgoutput=html 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. - Max -- http://mail.python.org/mailman/listinfo/python-list
Re: comparing alternatives to py2exe
On Nov 3, 5:58 pm, Jonathan Hartley tart...@tartley.com wrote: Hi, Recently I put together this incomplete comparison chart in an attempt to choose between the different alternatives to py2exe: http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdgoutput... 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: comparing alternatives to py2exe
On Tue, Nov 3, 2009 at 3:50 PM, iu2 isra...@elbit.co.il wrote: On Nov 3, 5:58 pm, Jonathan Hartley tart...@tartley.com wrote: Hi, Recently I put together this incomplete comparison chart in an attempt to choose between the different alternatives to py2exe: http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdgoutput... 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. py2exe supports this, cx_freeze doesn't. - Max -- http://mail.python.org/mailman/listinfo/python-list
Re: comparing alternatives to py2exe
Recently I put together this incomplete comparison chart in an attempt to choose between the different alternatives to py2exe: http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdgoutput=html ...snip... Are there major things I'm missing or misunderstanding? A quick note - although I haven't tried it out, the latest version of bbfreeze claims to support OSX. Ryan -- Ryan Kelly http://www.rfk.id.au | This message is digitally signed. Please visit r...@rfk.id.au| http://www.rfk.id.au/ramblings/gpg/ for details signature.asc Description: This is a digitally signed message part -- http://mail.python.org/mailman/listinfo/python-list
