I am trying to create an exe from python code. I can run the code just fine from the command line like this:
python myScript.py
I have installed py2exe from here: http://sourceforge.net/projects/py2exe/files/py2exe/0.6.9/
And, have a setup.py that looks like this:
from distutils.core import setup
import py2exe
setup(console=['myScript.py'])
And, I run the setup.py like this:
python setup.py py2exe
I get the following in the output:
The following modules appear to be missing
['Carbon', 'Carbon.Files', '__pypy__', '_scproxy', 'http_parser.http', 'http_parser.reader', 'jinja2._debugsupport', 'jinja2._markupsafe._speedups',
'jinja2.debugrenderer', 'markupsafe', 'pretty', 'socketpool', 'socketpool.util']
And, sure enough, if I try to run the exe, I get errors:
$ ./myScript.exe
Traceback (most recent call last):
File "restkit\__init__.pyc", line 9, in <module>
File "restkit\conn.pyc", line 14, in <module>
ImportError: No module named socketpool
Traceback (most recent call last):
File "myScript.py", line 12, in <module>
ImportError: cannot import name Resource
What do I need to do to get py2exe to find the dependencies?
Thanks
Carbon is the name of two different Mac-specific things.
First, in 2.x, on both Mac OS X and Mac Classic builds, has a Carbon package in the standard library, used for calling Carbon/Toolbox APIs (and, in OS X, CoreFoundation and friends).
Second, in both 2.x and 3.x, on Mac OS X, with PyObjC, the PyObjC wrapper around Carbon.Framework is named Carbon. (PyObjC isn't part of the stdlib, but it does come with Apple builds of Python, and most third-party builds besides python.org's official installers.)
Neither of these will exist on Windows.
py2exe tries to be smart and only import things relevant to your platform. However, it's pretty easy to fool. For example, something like this:
try:
import Carbon.Files
except:
Carbon = collections.namedtuple('Carbon', 'Files')
Carbon.Files = None
if Carbon.Files:
Carbon.Files.whatever(…)
… might make py2exe think Carbon.Files is required.
Now, obviously this isn't your whole problem, but it is a very big red flag that py2exe's module dependency code is not working for your project. You probably have similar problems with all kinds of other modules, so it's both missing some things you need and demanding some things you don't have, and this is probably what's causing your actual problems.
As the FAQ explains, you can debug this by running the module-finder code to see where it's going wrong, like this:
python -m py2exe.mf -d path/to/my_file.py
You could use this information to guide the module-finder code, or to rewrite your code so you don't confuse py2exe.
Or, more simply, just explicitly include and exclude modules in your setup.py as a workaround, without worrying about why they're getting incorrectly detected.
py2exe is python version dependent. Everything you're doing seems to be correct, I would guess you have the wrong version installed.
Related
I wrote a script in Spyder IDE, but in order for clients to use it, I would like to make it easier to run it then opening Anaconda and then Spyder and running it from there.
The reason I used Spyder was because it allowed me to use many modules that otherwise wouldn't be allowed on company stations.
I researched a lot but could not find a way to do this.
I was thinking of enveloping the script in a batch file and running it. I tried updating the python script to look for modules in the Anaconda default directories:
sys.path.insert(1, C:\\ProgramData\\Anaconda3\\python37.zip)
sys.path.insert(1, C:\\ProgramData\\Anaconda3\\DLLs)
sys.path.insert(1, C:\\ProgramData\\Anaconda3\\lib)
sys.path.insert(1, C:\\ProgramData\\Anaconda3)
sys.path.insert(1, C:\\ProgramData\\Anaconda3\\lib\\site-packages)
sys.path.insert(1, C:\\ProgramData\\Anaconda3\\lib\\site-packages\\win32)
sys.path.insert(1, C:\\ProgramData\\Anaconda3\\lib\\site-packages\\win32\\lib)
sys.path.insert(1, C:\\ProgramData\\Anaconda3\\lib\\site-packages\\Pythonwin)
sys.path.insert(1, C:\\ProgramData\\Anaconda3\\lib\\site-packages\\IPython\\extensions)
When running the script in Windows cmd, I got these errors when importing pandas module, so there is more to using Spyder then just accessing those modules (I couldn't figure out what):
Traceback (most recent call last):
File "script.py", line 32, in <module>
import pandas as pd
File "C:\ProgramData\Anaconda3\lib\site-packages\pandas\__init__.py", line 13, in <module>
__import__(dependency)
File "C:\ProgramData\Anaconda3\lib\site-packages\numpy\__init__.py", line 110, in <module>
import warnings
File "C:\ProgramData\Anaconda3\lib\warnings.py", line 494
f"coroutine '{coro.__qualname__}' was never awaited\n"
Another approach I tried was using pyinstaller, but that is not available for us and I cannot install it from the website.
Is there a way of running the python script and using all the modules offered by Anaconda without going through Spyder?
Have you tried py2exe? It's a great tool that does exactly what you're asking for.
Also look into cython. It's a lot easier to generate an executable from C code, and you'll get a performance boost as well.
Also try pyinstaller. It'll give you both an executable and settings for that, like icon or no-console. first go to the directory where your .py file is and run the below command:
pyinstaller script.py --onefile
Before this, you'll need to install that python module:
python* -m pip install pyinstaller
Where * is your specific python version, if you have multiple installed.
The first command will give you dist folder, here is where your executable is placed. and the script.spec file is your settings.
I'm using PyGObject/GTK+ with Python3.7 on Windows and is worried about how to package my app. With official Python ecosystem, it's easy to use freezers and venvs. However, the PyGObject and GTK+ on Windows requires the MingW environment to run.
Does this mean that I have to package the entire MingW, along with GTK+?
How should I freeze the app?
Since no one cares soon enough, I'll report my findings here. The short answer, as of the date I write this post, is: The PyGObject eco-system is not commercial-ready on Windows, although nothing stops you from shipping a functional app.
The deal-breaker is the lack of functional freezers on Windows for PyGOBject. So you can't really ship a closed-source commercial product with it (although one could argue that the entire Python eco-system is not made for that). The freezers that I tried:
The officially recommended PyInstaller right now does not install with the officially recommended msys/MingGW universe; Even after building PyInstaller from source, the frozen .exe crashes with complaints about missing modules. Below is the crash report from a hello-world app.
$ app.exe
[8340] mod is NULL - structTraceback (most recent call last):
File "C:/Apps/msys64/mingw64/lib/python3.7/struct.py", line 13, in <module>
from _struct import *
ModuleNotFoundError: No module named '_struct'
[8340] mod is NULL - pyimod02_archiveTraceback (most recent call last):
File "C:/Apps/msys64/mingw64/lib/python3.7/site-packages/pyinstaller-3.5-py3.7.egg/PyInstaller/loader/pyimod02_archive.py", line 28, in <module>
import struct
ModuleNotFoundError: No module named 'struct'
[8340] mod is NULL - pyimod03_importersTraceback (most recent call last):
File "C:/Apps/msys64/mingw64/lib/python3.7/site-packages/pyinstaller-3.5-py3.7.egg/PyInstaller/loader/pyimod03_importers.py", line 24, in <module>
from pyimod02_archive import ArchiveReadError, ZlibArchiveReader
ModuleNotFoundError: No module named 'pyimod02_archive'
Traceback (most recent call last):
File "site-packages/pyinstaller-3.5-py3.7.egg/PyInstaller/loader/pyiboot01_bootstrap.py", line 15, in <module>
ModuleNotFoundError: No module named 'pyimod03_importers'
[8340] Failed to execute script pyiboot01_bootstrap
cx_Freeze, another prominent alternative, does not build/install on MingW, either. You end up with gcc woes, no matter how many gcc variants you install.
py2exe is now abandonware since Python 3.4.
Since a PyGObject app still runs with MinGW python, it's not impossible to ship such an app for Windows. But that means you'll go with the big baggage and figure out a way to pack everything yourself. Let alone maintain the whole mess. Mind you that the procedure will be different on Mac if your app is cross-platform. PyInstaller works on Mac according to my test.
QuodLibet provides an example of how to ship an open-source software based on PyGObject. Unfortunately, as of today, the upstream's packaging procedure fails at the build.sh run on my Windows 10:
copying data/quodlibet.zsh -> E:\_dev\quodlibet\win_installer\_build_root\mingw64\share\zsh\vendor-completions\_quodlibet
Traceback (most recent call last):
File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 141, in <module>
main(sys.argv)
File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 130, in main
libs = get_things_to_delete(sys.prefix)
File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 108, in get_things_to_delete
for lib in get_dependencies(path):
File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 66, in get_dependencies
data = data.decode("utf-8")
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa3 in position 72: invalid start byte
This turns out to be an easy fix: locale issue on non-UTF8 Windows.
A trivial patch would be replacing "utf-8" with locale.getdefaultlocale(). After that, the build succeeds.
However, the global distribution issues remain challenging:
Bloated pipeline: The officially recommended msys2 build system basically drags the entire GNOME universe and much of the Python universe to your machine, while you may already have a Python environment on your native Windows. It proves hard to cherry-pick the necessary dependencies among this whole pile of stuff.
Extra C pipeline required to build the executable. To build a Windows executable without a freezer, you must create your app as a Python package (big hassle), install it to your msys2-Python site-packages (another setup.py hassle), and then build a wrapper C application using the Python C API (opaque hassle). The process is not transparent, especially when Python packaging system is sensitive to working directory and path differences. Launching the executable can easily go wrong without much debug info.
Manual stripping. As mentioned above, you must manually cherry-pick dependencies or your app would be shipped with basically the entire msys2/MinGW universe that's worth 100MB+ for a hello-world app.
I have seen many threads that have a high level of ambiguity and go off on tangents from the original question, often assuming much about the authors ability, so I am hoping that if I am direct and concise with my information, I will get an answer that is in line with the requirement. I know that the serious programmers will have seen this many times, in many formats, so please just bear with me as this is doing my head in. Please do not just post a link to some other answer as I rarely find that helps with my current issue.
I am not a hardcore programmer, I find the compiling, sourceball, tar, gz all nonsense to be honest and am looking for the easiest way to install sip for python on my machine. I have installed various versions of mingw32, mingw64 to the point that I don't know which one is best to use. I am assuming that the one here: C:\Program Files\mingw-w64 is the one, considering I am using 64 bit, but do the others I have installed impact on this?
I also installed versions of mysys:
C:\msys\1.0,
C:\msys64, but I still m unclear what and why etc, despite trying to read the docs that came with them.
I have windows 10, 64 bit professional edition.
I have python 2.7
I have installs of mingw, 32 bit and 64 bit in various locations, due mostly to not fully understanding what exactly it was or where it should go. I found zips of it and exes, so I got a bit confused.
I downloaded the sip package and unpacked it to here: C:\Python27\Lib\site-packages\sip-4.19.3 and it has the configure.py file in it. So far, so good.
I used a CMD window, changed directory to: C:\Python27\Lib\site-packages\sip-4.19.3 and then used the command: python configure.py to create the Makefile file which is what I believe is supposed to happen.
I then opened the mingw64 shell, changed directory to the above sip folder and typed: python configure.py again, just to be sure I would get a response and create the files again, probably should not have done so, but hey ho, at this point, I am quite frustrated with it and trying to do anything with what I have, which I know is poor practice. (see image 1.)
image 1: configure.py executed
From what I have read, I should use the make function that comes with Mingw64, but I tried the following, which also includes the configure.py code, but nothing seems to work when trying to use the Makefile file that was created via the configure.py process.
c:\Python27>cd ./Lib/site-packages/sip-4.19.3
c:\Python27\Lib\site-packages\sip-4.19.3> python configure.py
This is SIP 4.19.3 for Python 2.7.13 on win32.
The SIP code generator will be installed in C:\Python27.
The sip module will be installed in C:\Python27\Lib\site-packages.
The sip.pyi stub file will be installed in C:\Python27\Lib\site-packages.
The sip.h header file will be installed in C:\Python27\include.
The default directory to install .sip files in is C:\Python27\sip.
Creating siplib\sip.h...
Creating siplib\siplib.c...
Creating siplib\siplib.sbf...
Creating sipconfig.py...
Creating top level Makefile...
Creating sip code generator Makefile...
Creating sip module Makefile...
c:\Python27\Lib\site-packages\sip-4.19.3> Makefile
'Makefile' is not recognized as an internal or external command,
operable program or batch file.
c:\Python27\Lib\site-packages\sip-4.19.3> make Makefile
make: Nothing to be done for `Makefile'.
c:\Python27\Lib\site-packages\sip-4.19.3> Makefile Makefile
'Makefile' is not recognized as an internal or external command,
operable program or batch file.
c:\Python27\Lib\site-packages\sip-4.19.3>
So now I am at an impasse. I have the locations of my mingw versions and the msys in my path environment variable and I have done just about everything I have looked at on the web. I realise that its an order of things, but I really wish there were just executables for these modules and supporting tools as this compiling is a ball ache.I tried opening a python shell and importing sip.
>>> import os, sys
>>> import sip
Traceback (most recent call last):
File "<pyshell#1>", line 1, in <module>
import sip
ImportError: No module named sip
>>> import sipconfig
Traceback (most recent call last):
File "<pyshell#2>", line 1, in <module>
import sipconfig
ImportError: No module named sipconfig
>>> from sip import sip
Traceback (most recent call last):
File "<pyshell#3>", line 1, in <module>
from sip import sip
ImportError: No module named sip
>>> from sipconfig impport sip
SyntaxError: invalid syntax
>>> from sip import *
Traceback (most recent call last):
File "<pyshell#5>", line 1, in <module>
from sip import *
ImportError: No module named sip
So, if anyone has read through this and has a definitive answer as to what I am doing wrong, I would appreciate it.
make/nmake or make/nmake install cant be done from cmd and python path; instead using mingw or visual studio tools.
In windows search for prompt or Visual studio tools to open VS Command promt and from there cd--> sip file location (before this run configure.py present in sip folder)
Now run the commands nmake and then nmake install
I'm trying to build an app that uses some xml data using Python's built-in xml.etree.ElementTree class. It works properly when I run from the command line, but when I build it, I get an error "ImportError: No module etree.ElementTree." I'm guessing this is because I'm not importing that module correctly, but I haven't been able to figure out how. When I use the "includes" or "packages" directive, py2app complains with the same error, and when I specifically specify the package_dir (/System/Library/...), it compiles, but still gives me the error. I've included a short example to illustrate the issue.
macxml.py
from xml.etree.ElementTree import ElementTree
if __name__ == '__main__':
tree = ElementTree()
print tree.parse('lib.xml')
This should print out "< Element Library at xxxxxx>" where Library is the root name.
setup.py
from setuptools import setup
setup(name="Mac XML Test",
app=['macxml.py'],
)
What is the correct way to make the mac app utilize this library?
Python 2.6.4
Mac OS X 10.6.2
Edit: I also tried this on another mac (PPC 10.5.8) with Python 2.6.2 and achieved the same results.
After reinstalling and updating macholib, modulegraph, py2app, and setuptools to no avail, I did a little more digging and found the following error in the modulegraph module:
graphmodule.find_modules.find_modules(includes=['xml.etree'])
Traceback (most recent call last):
File "<stdin>", line 1 in <module>
File ".../modulegraph/find_modules.py", line 255 in find_modules
File ".../modulegraph/find_modules.py", line 182 in find_needed_modules
File ".../modulegraph/modulegraph.py", line 401 in import_hook
File ".../modulegraph/modulegraph.py", line 464 in load_tail
ImportError: No module named xml.etree
So I looked more into the load_tail and import_hook functions and found that for some reason it was importing the xml package correctly, but then went to an old install of _xmlplus to look for the etree subpackage (which of course it couldn't find). Removing the _xmlplus package eliminated the error and I was able to get the application to work with the following setup.py file:
from setuptools import setup
import xml.etree.ElementTree
setup(name="Mac XML Test",
app=['macxml.py'],
options={'py2app': {'includes': ['xml.etree.ElementTree']}},
data_files=[('', ['lib.xml'])]
)
The output shows up in the console.
Since the comment doesn't have good formating,
In find_modules.py I changed
REPLACEPACKAGES = {
'_xmlplus': 'xml',
}
To
REPLACEPACKAGES = {
#'_xmlplus': 'xml',
}
And the xml import worked.
If you're using macports (or fink etc.) make sure that py2app is using the correct interpreter. You may have to install a new version to work with 2.6.x (on OS X 10.5, py2app uses 2.4.x).
If that doesn't work my steps for working through path problems are:
Start up the python interpreter that your code (or py2app) uses (are you absolutely certain?? try which python)
import sys; print sys.path
If step 2. gives you a path in /System/Library..someotherpythonversion your code is running in the wrong interpreter.
I am trying to use py2exe to distribute a python application I have written. Everything seems to go OK, but when I run it on another machine it fails with the following error:
Traceback (most recent call last):
File "application.py", line 12, in <module>
File "win32api.pyc", line 12, in <module>
File "win32api.pyc", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.
I have googled for this and not found very much, but have tried the following suggestions to no avail:
Imported pywintypes and pythoncom before win32api (in the setup.py for py2exe and in the main application)
Added some code to the setup.py -
# ModuleFinder can't handle runtime changes to __path__, but win32com uses them
import pywintypes
import pythoncom
import win32api
try:
# if this doesn't work, try import modulefinder
import py2exe.mf as modulefinder
import win32com
for p in win32com.__path__[1:]:
modulefinder.AddPackagePath("win32com", p)
for extra in ["win32com.shell"]: #,"win32com.mapi"
__import__(extra)
m = sys.modules[extra]
for p in m.__path__[1:]:
modulefinder.AddPackagePath(extra, p)
except ImportError:
# no build path setup, no worries.
pass
I'm quite new to all this, so any help would be greatly appreciated
Thanks
Jon
I've seen this problem when the package was built on Vista but executed on XP. The problem turned out to be that py2exe mistakenly added powrprof.dll and mswsock.dll to the package. Windows XP contains its own copies of these files though, and can't load the Vista ones which got installed with your app.
Removing them from the package did the trick, you can do this easy by adding this to the options dict in setup.py
'dll_excludes': [ "mswsock.dll", "powrprof.dll" ]
#Wim, I found the bit about "adding this to the options dict in setup.py" a bit confusing. If like me you did not have an options arg in your existing call to setup this might make things clearer:
setup(name='myprog',
...
options={"py2exe":{"dll_excludes":[ "mswsock.dll", "powrprof.dll" ]}},
...
)
Try adding win32api to your packages, in the options dictionary.
Here's an example:
excludes = ["pywin", "pywin.debugger"] # there will be more in real life...
options = dict(optimize=2,
dist_dir="build",
excludes=excludes,
packages=["win32api"])
setup(
name="MyCoolApp",
options=dict(py2exe=options),
# etc ...
Just as an added comment. When rebuilding your program with Py2exe be sure to delete the old "dist" directory. I was sitting for over 3 hours not understanding why my app was working on my dev envirnoment and not in production. deleted dist and rebuild with py2exe and it worked.