pyinstaller with matplotlib windows - matplotlib

I use pyinstaller in generate pythion program with matplotlib a exe file
The exe is generated well but when use the exe, there is a error said no module named 'tz'
what does it mean?
I have test the pythinstaller with program with numby and pyqt4 without matplotlib, it worksenter image description here well! )

I have find the solution on pyinstaller git hub provided by Cecil Curry.
It is:
This is a known issue. python-dateutil 2.5.0 is currently broken with respect to PyInstaller, unfortunately.
Until python-dateutil issues a new stable release correcting this, consider temporarily downgrading to python-dateutil 2.4.2. Apologies for the mild inconvenience – and thanks for taking the time to report this, nonetheless.
I have tested and it works

Related

Packaging with Pyinstaller - PyQt5 setStyle ignored

I'm actually have an similar issue as described here after update python, pyistaller, pyqt5, pyqt5-tools. Before I got the desired "Windows Vista-style" without app.setStyle('windowsvista') when I run the compiled stand-alone executable.
Now I got the Windows "Classic-style" instead. If I start the application in PyCharm it will use the desired "Windows Vista-style".
Currently installed on Win7 64bit:
Python : 3.6.4
PyInstaller: 3.3.1
PyQt5 : 5.10
pyqt5-tools: 5.9.0.1.2 (update to 5.9.1.1 doesn't work)
Does anyone have any idea why PyInstaller ignored the style?
The error seems to have been fixed in a unmerged branch of PyInstaller. More information can be found on the GitHub pull request conversation, but reinstalling PyInstaller using pip install https://github.com/bjones1/pyinstaller/archive/pyqt5_fix.zip fixed the same style issue for me on Mac.

On win7 when import tensoreflow it shows "no module named_pywrap_tensorflow" after i do use the vc_redist

the redist(x86) is different from those answers provided before(x64).Is that the point?
Meanwhile it shows "Unless you are using bazel, you should try to import tensorflow from its source directory".But i didn't do that.
Ensure that you have Visual Studio Installed and that MSVCP140.DLL is on your computer AND in your PATH envVar. You shouldn't be building from source on Windows as it is not supported. I assume that you installed via pip?
Check for the DLL, VS, your PATH variables and, if that doesn't work, redownload the vc_redist_x64 version.
Failing that, uninstall Tensorflow and try again with pip install tensorflow or from a nightly. I had a similar issue and starting fresh seemed to help.

Python Packaging Fix: Understand Differences between Wheel and Egg; How to get local fix to wider audience?

I'm trying to understand why the easy_install of pyicu works and pip install doesn't (see below). also trying to understand "What is the difference between a PyPi project with a universal wheel and one without?" Will installs be "easier?". If so, will this merge request solve the problem of polyglot not installing on an Anaconda machine?
Need help/advice/solutions on how to best resolve python project install issue that is tied to underlying dependencies. I have two local fixes in GitHub Gists but would like to know the best way to have this fix "out there" so people like me can find it. What is the normal Python Community approach? The problem centers around three projects:
polyglot - a python multilingual NLP toolkit
pyicu - Python extension wrapping IBM's International Components for Unicode C++ library (ICU).
pycld2 - CLD (Compact Language Detection) library as maintained by Dick Sites
The goal:
Install polyglot on a MacOSX computer running Python Anaconda Distribution
Make the fix I found available to everyone; lots of issues published about the problem.
Here's the error trace:
The Problem (Lots of them):
Core polyglot dependency, pyicu, does not properly install when you use pip install. Discovered you must use easy_install for it build properly and work on MacOSX. If you don't use the easy_install, you get:
polyglot requires icu 54.1.1 to run in Anaconda, but...
Homebrew, the MacOSX tool to install icu, only installs version 58.1. That version is too new. Old stackoverflows advise brew install icu4c to fix problem, but Homebrew evolution makes that advice obsolete now.
pyicu does not have a universal wheel; but I created a merge request to add one to pyicu. Only way to fix this is with this channel's icu, https://anaconda.org/ccordoba12/icu. conda install icu will not work, but that's the normal conda way of doing things.
*pycld2 - CLD (Compact Language Detection) becomes a problem because after I build the wheel file locally, have to download the project and run setup.py install locally. There has to be a better way to do this right?
What I've Done to Solve the problem (should I do more, what should I do next?)
Created two Gists that can successfully install polyglot on a Mac running Anaconda for Python 2.7 or Python 3.5
Python 2.7 fix
Python 3.5 fix
created the merge request for pyicu
Both Gist fixes work. But, is this error in install tied to the wheel? If I installed pyicu with easy_install, the install works. But, with pip, it doesn't?
What are the steps to take in the Python community to fix it so people can find the solution or just pip install with no problems?
I did a test, and if the wheel file is built, the pip works with no issues.

Forced to install GDAL 1.11 framework by package for QGIS, and failing

To install QGIS on my MacBook Pro I need to install the gdal framework; however, the 1.11 framework package needed for QGIS is an empty file at kyngchaos. I tried installing GDAL 1.10 complete, but QGIS is requiring 1.11. I have Mavericks. I've installed each individual package: UnixImageIO, PROJ, GEOS, SQLite2, numpy, rgdal, and on... Now when I run the GDAL 1.11 framework install, everything seems to run until the last page, where an "Install Fail" page shows up. When I try to view the error, I'm taken out of the installer.
After some googling, I tried installing using homebrew. (brew install gdal)... I got a little further, but it tells me to "brew link libpng libtiff" -- and when I run that command, I get:
Linking /usr/local/Cellar/libpng/1.5.14... Warning: Could not link libpng. Unlinking...
Error: Could not symlink file: /usr/local/Cellar/libpng/1.5.14/share/man/man3/libpngpf.3
/usr/local/share/man/man3 is not writable. You should change its permissions.
After some more searching, it seems I could change permissions from usr/local to me, but I'm not sure how to (exactly) and don't want to mess anything up. Any help would be greatly appreciated, and my apologies if I'm missing something painfully obvious! I'm a novice at the programming end of things, so am just kind of pushing through everything like a bull in a china shop.
UPDATE:
Okay, I found the answer, even though it didn't seem to be working initially--
I ran the following commands from the GDAL help documentation:
export PATH=/Library/Frameworks/GDAL.framework/Programs:$PATH
sudo ln -sfh [ver] /Library/Frameworks/GDAL.framework/Versions/Current
in Terminal, and the framework was updated. If I run the GDAL 1.11 installer it still shows up as a failed installation, BUT QGIS recognizes 1.11 as the installed, so that's great.
(I just needed to install matplotlib in addition, and QGIS was installed successfully.)
It seems that the GDAL Complete framework was just updated 3 days ago, so it should be a temporary error until they realize the package is empty.

Mac OS Snow Leopard, IPython Notebook matplotlib backend mismatch with libpng

The other day I was trying to delve deeper into this question and provide some insights. Maybe with the additional insights it can finally be solved.
Things to note:
Installing a different Python version is not an option for me (I'd do it in a heartbeat) because I need to use the Gurobi linear programming solver.
matplotlib is compiled with libpng 1.5.14 and linked at runtime just fine. In the IPython console I can use it to plot png figures perfectly.
Because of the previous point I believe the error must occur with the backend used in the IPython Notebook which is also compiled with matplotlib.
I'm trying the whole thing with the source for matplotlib 1.3, if someone can make it work with a previous, not too old version I'd be happy, too.
So, when I try to plot something in the Notebook I get the normal text output from matplotlib put no figure. In the terminal where I started the notebook, I can see the following error:
libpng warning: Application built with libpng-1.2.41 but running with 1.5.14
Since I concluded earlier that the problem must lie in the backend, I checked what libraries are linked there:
otool -L /Library/Python/2.6/site-packages/matplotlib-1.3.0-py2.6-macosx-10.6-universal.egg/matplotlib/backends/_tkagg.so
The output on my system was:
/Library/Python/2.6/site-packages/matplotlib-1.3.0-py2.6-macosx-10.6-universal.egg/matplotlib/backends/_tkagg.so:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility version 8.5.0, current version 8.5.7)
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility version 8.5.0, current version 8.5.7)
So the likely offending candidates are Tcl and Tk. Then I ran:
find /System -name libpng\*
and indeed I find:
/System/Library/Tcl/8.4/Img1.4/libpngtcl1.2.24.dylib
/System/Library/Tcl/8.5/Img1.4/libpngtcl1.2.24.dylib
as well as Python shipping its own:
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/libpng.3.dylib
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/libpng.dylib
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/libpng12.0.dylib
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/libpng12.dylib
I went ahead and downloaded the source code for Tcl/Tk 8.6 and compiled them myself in the hope of them compiling against libpng but that wasn't the case. I still got the same error:
libpng warning: Application built with libpng-1.2.41 but running with 1.5.14
When I compile matplotlib it says that due to patches it ships its own libagg and I can't find which tkagg it is using, so maybe that's where things go wrong? Or is the Python 2.6 provided by the system compiled with Tk which is linked against that older libpng?
I guess I could try compiling matplotlib against the libpng version of Tcl/Tk 8.5 or against the one available in the Python framework and see if then both run on libpng version 1.2.41.
Does anyone know where in the backend this might occur and how to fix the compilation to use the right libpng version?
Have you solved the problem yet? I have a similar issue, and I solved it by temporarily renaming the folder containing the header files of libpng shipped with Python (in my case, it's X11) when building matplotlib. After installing matplotlib, rename the folder back.