(I have already resolved this issue but it cost me two weeks of my time and my employer a couple of grand, so I'm sharing it here to save some poor soul.)
My company is converting our application from 32-bit to 64-bit. We create an executable using py2exe, using the bundle=2 option. The executable started crashing as soon as it tried to render a matplotlib plot.
Versions:
python==2.7.13,
matplotlib==2.0.0,
numpy==1.13.1,
py2exe==0.6.10a1
I tracked the error to the numpy library. Numpy calls numpy.linalg._umath_linalg.inv() and the program abruptly exits with no error message, warning, or traceback.
_umath_linalg is a .pyd file and I discovered that this particular .pyd file doesn't like being called from library.zip, which is where py2exe puts it when using bundle option 2 or 1.
The solution is to exclude numpy in the py2exe setup script and copy the entire package folder into the distribution directory and add that directory to the system path at the top of the main python script.
Related
I am trying to use matploitlib_cpp on Windows 11 with Numpy 1.24.2 and Python 3.11, but I keep running in to the following error.
Original error was: No module named 'numpy.core._multiarray_umath'
I know this has been posted at a million different places on the internet and I have tried following all the guides that says reinstalling numpy and whatever, it does not work for me. What I can see in my path ..\Python3.11\Lib\site-packages\numpy\core is that I have a file named _multiarray_umath.cp311-win_amd64.pyd but no file named _multiarray_umath. I also tried to use a virtual environement from Anaconda but I am not sure how to build matploitlib_cpp against such virtual enviornment.
I got it working by using the release binaries instead of debug binaries.
So, I'm working on a robotframework test project, and the goal is to run several test suites in parallel. For this purpose, pabot was chosen as the solution. I am trying to implement it, but with little success.
My issue is: after installing Pabot (which, I might say, I did by cloning the project and running "setup.py install", instead of using pip, since the corporate proxy I'm behind has proven an obstacle I can't overcome), I created a new directory in the project tree, moved some suites there, and ran:
pabot --processes 2 --outputdir pabot_results Login*.robot
Doing so results in the following error message:
2018-10-10 10:27:30.449000 [PID:9676] [0] EXECUTING Suites.LoginAdmin
2018-10-10 10:27:30.449000 PID:400 EXECUTING Suites.LoginUser
2018-10-10 10:27:30.777000 PID:400 FAILED Suites.LoginUser
2018-10-10 10:27:30.777000 [PID:9676] [0] FAILED Suites.LoginAdmin
WARN: No output files in "pabot_results\pabot_results"
Output:
[ ERROR ] Reading XML source '' failed: invalid mode ('rb') or filename
Try --help for usage information.
Elapsed time: 0 minutes 0.578 seconds
Upon inspecting the stderr file that was generated, I have this message:
Traceback (most recent call last):
File "C:\Python27\Lib\site-packages\robotframework-3.1a2.dev1-py2.7.egg\robot\running\runner.py", line 22, in
from .context import EXECUTION_CONTEXTS
ValueError: Attempted relative import in non-package
Apparently, this has to do with something from the runner.py script, which, if I'm not mistaken, came with the installation of robotframework. Since manually modifying that script does not seem to me the optimal solution, my question is, what am I missing here? Did I forget to do anything while setting this up? Or is this an issue of compatibility between versions?
This project is using Maven as the tool to manage dependencies. The version I am running is 3.5.4. I am using a Windows 10, 64bit system; I have Python 2.7.14, and Robot Framework 3.1a2.dev1. The Pabot version is 0.44. Obviously, I added C:\Python27 and C:\Python27\Scripts to the PATH environment variable.
Edit: I am also using robotframework-maven-plugin version 1.4.0.8, if that happens to be relevant.
Edit 2: added the error messages in text format.
I believe I've come across an issue similar when setting up parallel execution on my machine. Firstly I would confirm that pabot is installed using pip show robotframework-pabot.
Then you should define the directory your results are going to using -d.
I then modified the name of the -o to Output.xml to make it easy to identify.
This is a copy of the code I use. Runs optimally with 8 processes
pabot --processes 8 -d results -o Output.xml Tests
Seems that you stumbled on a bug in the prerelease version of robot framework (3.1a2.dev1).
Please install a release version of robot framework. For example 3.0.4.
Just in case anyone happens to stumble upon this issue in the future:
Since I can't use pip, and I tried a good deal of workarounds that eventually made things more unstable, I ended up saving my project and removing everything Python-related from my system, so as to allow me to install everything from scratch. In a Windows 10, 64bit system, I used:
Python 2.7.14
wxPython 2.8.12.1, win64, unicode, for py27
setuptools 40.2.0 (to allow me to use the easy_install command)
Robot Framework 3.0.4
robotremoteserver 1.1
Selenium2Library 3.0.0
and Pabot version 0.45.
I might add that, when installing the Selenium2Library the way I described above, it eventually tries to download some things from the pip repositories - which, if you have a proxy, will cause you trouble. I solved this problem by browsing https://pypi.org/simple/selenium/, manually downloading the 2.53.6 .tar.gz file, then extracting it and running setup.py install on the command line.
PS: Ideally, though, anyone should be able to use proxy settings from the command line (--proxy http://user:password#server:port) to get pip and then use it; however, for some reason, probably related to network security configurations that I didn't want to lose time with, this didn't work in my case.
Update
If I try downgrading from Pyinstaller 3.2 to 3.1 I instead get the following traceback when I try to run the executable.
I tried adding --hidden-import=collect_submodules('pkg_resources._vendor') to pyinstaller as noted here but it had no effect. Same error. This appears to be due to an issue with setuptools. I'm using 26.0.0. Downgrading to 19.3 that many sources say fixes the issue does indeed fix this issue but then I'm back to the issue I have below.
I have a python 2.7 pyqt4 project I'm trying to turn into an .exe using pyinstaller. I use:
pyinstaller --additional-hooks-rir=. --clean --win-private-assemblies pipegui.py
pipegui.py can be found on github here
I get a working executable and the app appears functional. Here is what the terminal spits while pyinstaller is freezing. However the app crashes when I run particular parts of my program. It crashes and the terminal goes in a loop continually outputting the same traceback below with "Poolworker-X" at the very top continually incrementing:
As you can see tkinter is implicated, despite the word "tkinter" appearing nowhere in my project (using pyqt4). I am making use of matplotlib though and from answers discussed here and here I have added the following to the top of pipegui.py my main script:
from Tkinter import *
import Tkinter
import FileDialog
This however seems to be a step in the wrong direction because after freezing with this (and the same flags as before) my executable wont even open and instead I get this:
Here is pyinstaller's pretty-much identical output while freezeing. Remember all I did was add those 3 import statements above. That's it.
I also tried pyinstaller --additional-hooks=. --clean --win-private-assemblies --hidden-import=Tkinter pipegui.py and it made no difference. I'm completely perplexed as to why trying to import tkinter is doing this. Will fixing this traceback lead me closer to solving the other?
I only figured out after trying all this that the only parts of my executable that are crashing are parts that make use of parmap multiprocessing. Classes that make use of matplotlib but not parmap are working fine.
So please note my question is how the first traceback can be fixed and also why are both matplotlib and tkinter popping up in the traceback despite my code where the crash occurs making use of niether?
Extra notes
I use --clean --win-private-assemblies to fix error code 14001 as per here
Repiklis provided the solution in the comments. Further note that as of January 15 2017 Pyinstaller version 3.2.1 was released. I now use this and it solves this issue along with others like this and this that I could previously only solve by using the developer version. So I highly recommend upgrading to the latest version if you haven't already.
Good day all. First time stack overflow has not previously answered an issue that I have. My problem is exactly like the one posted here, except I am running windows:
Google App Engine Launcher is not running my hello world for Python Mac
The only thing the log gives me is this
2016-08-18 13:39:13 Running command:
"['C:\Users\Kesi\Desktop\Documents\Computer
Science\Udacity\Intro to backend\hello-udacity\main.py',
'C:\Program Files (x86)\Google\google_appengine\dev_appserver.py',
'--skip_sdk_update_check=yes', '--port=8080', '--admin_port=8000',
'C:\Users\Kesi\Desktop\Documents\Computer Science\Udacity\Intro
to backend\hello-udacity']"
Any suggestions are greatly appreciated.
Converting comments to an answer.
The 1st argument in the command list from your message is 'C:\Users\Kesi\Desktop\Documents\Computer Science\Udacity\Intro to backend\hello-udacity\main.py', preceeding the dev_appserver.py suggests a configuration problem.
In the google app engine preferences section there is a place to specify the path to executable python file. That should not be set to your app's python file (as you have it), but to the actual python executable (from your python installation) - which executes dev_appserver.py (the 2nd arg in the command list) which in turn loads the subsequent command list args including one which is the one specifying your app code's location - the last one in your case.
The python executable could be a python.exe or pythonw.exe according to the Executing scripts section of Using Python on Windows doc:
Python scripts (files with the extension .py) will be executed by
python.exe by default. This executable opens a terminal, which stays open even if the program uses a GUI. If you do not want this to
happen, use the extension .pyw which will cause the script to be
executed by pythonw.exe by default (both executables are located
in the top-level of your Python installation directory). This
suppresses the terminal window on startup.
I'm working on converting a simple GUI script written with Python 2.7 and Pyqt4 into a standalone executable using py2exe. I keep getting "no such file exists" errors, and I've managed to fix a few, though this one seems stubborn. It can't find msvcp90.dll, and returns an error message with a short traceback to distutils and then back to my py2exe script, which isn't very enlightening.
I've installed the MS C++ redistributable runtime, as recommended in
py2exe fails to generate an executable
but my script still can't locate the .dll. Below is my py2exe script, with the name of my script blocked out:
from distutils.core import setup
from py2exe.build_exe import py2exe
import sys, os, zmq
sys.argv.append('py2exe')
os.environ["PATH"] = \
os.environ["PATH"] + \
os.path.pathsep + os.path.split(zmq.__file__)[0]
setup(
options = {'py2exe':{'bundle_files':1,"includes":["zmq.utils",
"zmq.utils.jsonapi","zmq.utils.strtypes"]}},
console = [{'script':"#######.py"}],
zipfile = None
)
I've already fixed an issue with zmq (which isn't ever used by my script, or my GUI, for that matter, as far as I know). What am I doing wrong?
Right, I've managed to get my app to build, and although the question is now moderately old, it's my hope this is eventually of use to someone.
Firstly, py2exe is probably the wrong tool. It's old and AFAICT unmaintained. Consider PyInstaller instead. Using PyInstaller is literally as simple as installing it, installing PyWin32, and then going python %path_to_pyinstaller%/pyinstaller.py --onefile --windowed source.py. PyInstaller deals with all the mess of side by side assemblies and so on without you having to do anything.
In short, use PyInstaller.
However, to answer your question, this worked for me:
The question you've linked to - in particular this answer is the right start. Find the right DLLs and copy them to C:\Python27\DLLs
Ditch your existing setup.py file. If you're not using zmq, there's no reason to import it. Also, for a windowed application you want windows= not console=. My file goes (for packaging show.py):
#!/usr/bin/python
from distutils.core import setup
import py2exe
setup(options={'py2exe':{'bundle_files':1}},
windows=['show.py'])
(This is pinched off http://www.blog.pythonlibrary.org/2010/07/31/a-py2exe-tutorial-build-a-binary-series/)