I have a problem: I used py2exe for my program, and it worked on my computer. I packaged it with Inno Setup (still worked on my computer), but when I sent it to a different computer, I got the following error when trying to run the application: "CreateProcess failed; code 14001." The app won't run.
(Note: I am using wxPython and the multiprocessing module in my program.)
I googled for it a bit and found that the the user should install some MS redistributable something, but I don't want to make life complicated for my users. Is there a solution?
Versions:
Python 2.6.2c1,
py2exe 0.6.9,
Windows XP Pro
You need to include msvcr90.dll, Microsoft.VC90.CRT.manifest, and python.exe.manifest (renamed to [yourappname].exe.manifest) in your install directory. These files will be in the Python26 directory on your system if you installed Python with the "Just for me" option.
Instructions for doing this can be found here.
Don't forget to call multiprocessing.freeze_support() in your main function also, or you will have problems when you start a new process.
While others have discussed including the MSVC runtime in your install package, the above solution works when you only want to distribute a single .zip file containing all your files. It avoids having to create a separate install package when you don't want that additional complication.
You should be able to install that MS redistributable thingy as a part of your InnoSetup setup exe.
When you run py2exe, look closely at the final messages when it's completed. It gives you a list of DLLs that it says are needed by the program, but that py2exe doesn't automatically bundle.
Many in the list are reliably available on any Windows install, but there will be a few that you should manually bundle into your Inno Setup installation. Some are only needed if you want to deploy on older Windows installs e.g. Win 2000 or earlier.
You can ship the runtime DLLs in question with your application as a "private assembly". This simply means putting a copy of a specially-named directory containing the runtime DLLs and their manifests alongside your executable.
See my answer to this post.
Related
I need to package my Python application, its dependencies, and Python itself into a single MSI installer for distribution to users. The end result should desirably be:
Python is installed in the standard location
the package and its dependencies are installed in a separate directory (possibly site-packages)
the installation directory should contain the Python uncompressed and a standalone executable is not required
Kind of a dup of this question about how to make a python into an executable.
It boils down to:
py2exe on windows, Freeze on Linux, and
py2app on Mac.
I use PyInstaller (the svn version) to create a stand-alone version of my program that includes Python and all the dependencies. It takes a little fiddling to get it to work right and include everything (as does py2exe and other similar programs, see this question), but then it works very well.
You then need to create an installer. NSIS Works great for that and is free, but it creates .exe files not .msi. If .msi is not necessary, I highly recommend it. Otherwise check out the answers to this question for other options.
My company uses the free InnoSetup tool. It is a moderately complex program that has tons of flexibility for building installers for windows. I believe that it creates .exe and not .msi files, however. InnoSetup is not python specific but we have created an installer for one of our products that installs python along with dependencies to locations specified by the user at install time.
I've had much better results with dependencies and custom folder structures using pyinstaller, and it lets you find and specify hidden imports and hooks for larger dependencies like numpy and scipy. Also a PITA, though.
py2exe will make windows executables with python bundled in.
py2exe is the best way to do this. It's a bit of a PITA to use, but the end result works very well.
Ok, I have used py2exe before and it works perfectly except for one thing... It only works on executable windows machines. I then learned about Jython which turn a python script into a .Jar file. Which as you know is executable from any machine that has Java ("To your latest running version") installed. Which is great because both unix, windows, and ios (Most of the time) Run java. That means its executable from all of the following machines. As long as they run Java. No need for "py2mac + py2exe + freeze" just to run on all operating systems. Just Jython
For more information on how it works and how you can use it click here.
http://www.jython.org/
I created a Python script for a Freelance job and I can't find how to compile/build/package it for easy sharing. The person for which I created it is not a technical one, so I can't explain him how to activate a virtualenv, install requirements and so on.
What is the easiest way for him to run the project right after downloading it?
Can the whole virtualenv be compiled into an .exe? If yes, can this be done inside a macOS system?
Yes you can package your python programs and it's dependencies with
Cx_Freeze
There are other python modules that do the same, personally i prefer cx_Freeze because it's cross platform and was the only one that worked out of the box for me.
By default cx_Freeze automatically discovers modules and adds them to the exe to be generated. but sometimes this doesn't work and you might have to add them by yourself
To create a simple executable from a file. you can just use the bundled cxfreeze script
cxfreeze hello.py --target-dir dist
but more for more complex applications that have different files you'll have to create a distutils setup script.
Note that cx_freeze doesn't compile your code like a traditional compiler. it simply zips your python files and all it's dependencies ( as byte code) together, and includes the python interpreter to make your program run. So your code can be disassembled. (if anyone wants to) and you'll also notice that the size of your program would be larger than it was initially (Because of the extra files included)
I ended up using PyInstaller as this worked out of the box for me.
my directroty sturcture is
/src (the source code directory including images)
/src/main.py (main script)
/src/subprojectfile/ (it consist of other several project file include __init__.py)
In my project I am using google procolbuffer,pygtk and other common python package like sys,time,thread etc..
I want to build an installer for non python system where user can install my application with out any python support.
For an alternative approach you might check out PyInstaller. It doesn't produce a proper installer, but rather standalone executables without external dependencies.
For windows you can use py2exe and for Linux have a look at freeze.
Is there a workable and proven way to freeze a pyqt4 application in windows? I heard that there are some issues for py2exe.
I used py2exe for a PyQt4 project at work but ended up switching to PyInstaller.
py2exe worked great for the most part. I remember having to manually tell it to include the sip libraries in my setup.py file along with some others depending on the program. PyInstaller seems to handle this better in my opinion, although I often find myself removing DLL files from the final folders' qt4_plugins folder that it has decided to include that I don't actually need. For example, qt4_plugins\imageformats\qjpeg4.dll when I'm not using JPEG files at all. This does not hinder the frozen application in any way, it'll just increases the filesize.
The manual for PyInstaller is pretty good as well and with it's 'Getting Started' section you should quickly be able to get things set up. It's as simple as creating a .spec file per project which is automatically generated but is also a normal Python file so that you have the option to tweak it or add any extra tasks such as code signing or maybe creating a setup.exe program using NSIS.
I have a windows batch file named pybuild.bat in my path who's contents consist of:
python -O c:\python27\pyinstaller-1.5\build.py "%~f1"
so that I can easily build a project from the command line by running 'pybuild projectname.spec' on the projects .spec file. I've also added this to the registry's entry for the .spec file so that I can freeze a project quickly from Explorer:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.SPEC\shell\Freeze\command]
#="C:\\Python27\\Scripts\\pybuild.bat \"%1\""
My main reason for switching from py2exe though is that some users complained that the frozen apps would not run on their machines. I kept running into the error:
The application has failed to start
because the application configuration
is incorrect. Reinstalling the
application may fix the problem.
but only on some machines, usually running Windows XP. I found that getting the user to install the Microsoft Visual C++ 2008 Runtimes made the problem go away.
Frozen apps created with PyInstaller didn't have this problem as it seems to package these runtimes into the output folder. If UPX is available somewhere in your path it will compress your DLL and PYD files as well, resulting in a smaller output folder.
Long story short - both py2exe and PyInstaller work fine. I hit a few issues with py2exe when using it and although there may be workarounds for these if you hunt around I found that PyInstaller worked better without any modifications. I've distributed frozen apps from PyInstaller that make use of image and database libraries from PyQt4 as well as a few other third party libraries and haven't hit any problems yet.
In continuing to research a solution for this question on ServerFault:
https://serverfault.com/questions/221203/mercurial-hook-fails-on-windows
I discovered an interesting and somewhat disturbing thing: I have seem three different versions of Python on my machine (four if you count the "official" version which doesn't appear to have a DLL with it....). Here's shot from my file search tool:
More Info:
I am running Windows 7 64-bit
Both the TortoiseHG and the Mercurial directories are on my path, with the Mercurial directory listed first.
I have Python 2.6 installed in c:\Python26
I have no entry for any type of PYTHON-based environmental variable. (Should I?)
I suspect that this is the source of the my problem from the question above, but I thought I'd ask here, as this is particular issue is a Python deal.
I tried to replace both DLLs with each other, but when I use the one that comes with Mercurial, then TortoiseHg stops working.
It seems to me that "there should only be one" Python on my machine. How do I achieve that?
For the problem that you mentioned earlier, the mercurial package got installed within python under mercurial home but you are executing scripts under C:\python26. So you need to install and execute your script under mercurial python
As seth mentioned earlier it is perfectly ok to multiple python homes in the same machine but you just to pay attention when installing python libraries to make sure that you are under the right home which means you set the path right before calling python.
Side note: The Python installation in "C:\Python26" installs its DLL to the Windows directory, in your case "C:\Windows\SysWOW64".
Answering your serverfault question: As you installed Mercurial as standalone version, you'll have to place any packages that are accessed by hooks into Mercurial's library folder (if it has one, could also be "library.zip").
I would recommend you to uninstall the Mercurial standalone version and instead install Mercurial with pip. This makes updates easier and you can use your normal "site-packages" directory for both normal Python libraries and hg hooks.
I would assume that tortoise/mercurial have just embedded their own versions of python to do whatever they need to do.
I wouldn't worry about it, the DLLs won't stomp on each other -- the PATH is the last placed that windows searches to find DLLs.
See: http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx
Each DLL is for that application. There is only one in your search path so you don't need to worry about conflicts.
Is something not working that prompted you to worry about this??
Your assumption that there should only be one is wrong, each application has bundled a specific version with a fixed API, you can't just drop another in and hope it'll work.
The Python DLL naming structure only provides the major version and revision numbers. You are probably looking at the DLLs for versions 2.6.1, 2.6.4, 2.6.5, and 2.6.6.
All of this doesn't really matter as long as each application contains its own copy of the python26.dll. Windows will not explore the PATH environment variable if there is a local copy of the file.