I run following python script.
pygame2exe.py
ImportError: No module named japanese
What's wrong?
Do not you know solutions?
The script makes use of japanese encoding
# -*- coding: sjis -*-
[...]
args.append('japanese,encodings');
It's a shame cause it could use UTF-8 that works out of the box.
You can't run this script unless you install the japanese module. I can't find any reference of it on the web, and I can read in the code :
# make standalone, needs at least pygame-1.5.3 and py2exe-0.3.1
# fixed for py2exe-0.6.x by RyoN3 at 03/15/2006
If you haven't installed the last version of pygame and py2exe, I would start by that since they may embed the module you need.
To add to e-satis' explanation, the "japanese" module is provided by the Japan PUG, but I don't think you've actually needed it since around Python 2.2. I believe that all the Japanese codecs are included in a standard Python install these days. I certainly don't use this module, and I handle SJIS in my programs just fine.
So I think you could just get rid if the forced import, and do fine. That is, delete these lines:
args.append('-p')
args.append('japanese,encodings') # JapaneseCodecを強制的に含める
Since you don't have the "japanese" module on your system, if the program runs OK on your system, then the frozen version should be OK without this module.
However, I would recommend using Unicode throughout instead of byte strings, and if you insist on byte strings, I'd at least put them in UTF-8.
Related
Here is my system info:
123 INFO: PyInstaller: 4.0
123 INFO: Python: 3.5.4
124 INFO: Platform: Windows-10-10.0.18362-SP0
I've been trying to generate a Python (PyQt) executable using Pyinstaller to be used in an app. However, when I package the executable and run it, it will throw this:
pkg_resources.DistributionNotFound: The 'flask-compress' distribution was not found and is required
by the application
[14684] Failed to execute script main
This dependency already exists in my virtual environment and I have tried specifying the path to the site packages directory and the flask_compress import like this:
pyinstaller --paths C:\Users\alan9\PycharmProjects\PracticumProject\venv\Lib\site-packages --hidden-import=flask_compress main.py
Note: I have tried to create the executable for this application using different python versions, with different pyinstaller flags (onefile, windowed, onedir), on different computers with Windows 7/10, on a clean copy of a Windows 10 VM, and with fbs but I always receive the same error message:(
I solved this problem with monkey patching. Just paste this code in a module that you import before dash and you should be good to go. In my case I had flask-compress==1.5.0 so I just hardcoded the version but you could probably do something more clever.
"""
Simple module that monkey patches pkg_resources.get_distribution used by dash
to determine the version of Flask-Compress which is not available with a
flask_compress.__version__ attribute. Known to work with dash==1.16.3 and
PyInstaller==3.6.
"""
import sys
from collections import namedtuple
import pkg_resources
IS_FROZEN = hasattr(sys, '_MEIPASS')
# backup true function
_true_get_distribution = pkg_resources.get_distribution
# create small placeholder for the dash call
# _flask_compress_version = parse_version(get_distribution("flask-compress").version)
_Dist = namedtuple('_Dist', ['version'])
def _get_distribution(dist):
if IS_FROZEN and dist == 'flask-compress':
return _Dist('1.5.0')
else:
return _true_get_distribution(dist)
# monkey patch the function so it can work once frozen and pkg_resources is of
# no help
pkg_resources.get_distribution = _get_distribution
I was experiencing a similar problem and this solution was not working for me in an environment with pyinstaller==4.0, dash==1.17.0 and flask_compress==1.8.0.
However, I found that the solution proposed by Legorooj here works quite well in my case, basically instead of tensorflow one uses flask and flask_compress in the hook file.
For completeness here is how I wrote the hook-flask.py file.
from PyInstaller.utils.hooks import collect_all
def hook(hook_api):
packages = [
'flask',
'flask_compress',
'flask_caching'
]
for package in packages:
datas, binaries, hiddenimports = collect_all(package)
hook_api.add_datas(datas)
hook_api.add_binaries(binaries)
hook_api.add_imports(*hiddenimports)
Of this way no monkey patching is needed.
second update:
Since I cannot put comments yet (not enough contributions on stackoverflow?) I am adding this update to say that I tried the hook-based solution (which, in theory is the best way to deal with this sort of problem), but like Sören reported, this did not seem to get flask-compress into the distribution.
update:
The monkey-patching solution is clearly preferable, both because it leaves the flask code intact (and apparently the original functionality), but also because it (presumably) identifies the true underlying problem -- flask-compress is being brought along for the ride but simply isn't detected by pkg_resources... I wonder what (if anything) can be done to generalize this -- it may be possible to modify pkg_resources to work in a "bundled" Pyinstaller context.
original post:
I got hit with the exact same problem. Now, the "correct" thing to do is to figure out the apparently subtle way to add a proper Pyinstaller hook to take care of this issue. Maybe I will get around to doing that at some point -- certainly, what you tried to do makes sense and should've worked. I did the even more basic move of explicitly importing flask_compress in the main python script, without success.
However, since we are both trying to Pyinstallerize a flask-dependent (desktop) application, chances are very good that neither of us actually needs to gzip the responses that are being generated, so it is possible to eliminate the whole problem by "simplifying the software a bit". In my case, the references to flask_compress came from dash, so I ripped out the gzip functionality (found in Lib/site-packages/dash/dash.py). The key relevant references are on lines 21, 53, 292, 321 and 432.
"Rewire" references like those (in whatever library you use which references flask-compress) and all your problems magically disappear -- worked for me :-)
My bet is that line 53 engages machinery that is too clever/dynamic for Pyinstaller. Don't get me wrong -- Pyinstaller is nothing short of a miracle but as a community we will be forever running around trying to plug these clever-hacks because Python simply was not made to generate nice standalone executables.
I am switched from Python 2.7 to Python 3.6.
I have scripts that deal with some non-English content.
I usually run scripts via Cron and also in Terminal.
I had UnicodeDecodeError in my Python 2.7 scripts and I solved by this.
# encoding=utf8
import sys
reload(sys)
sys.setdefaultencoding('utf8')
Now in Python 3.6, it doesnt work. I have print statements like print("Here %s" % (myvar)) and it throws error. I can solve this issue by replacing it to myvar.encode("utf-8") but I don't want to write with each print statement.
I did PYTHONIOENCODING=utf-8 in my terminal and I have still that issue.
Is there a cleaner way to solve UnicodeDecodeError issue in Python 3.6?
is there any way to tell Python3 to print everything in utf-8? just like I did in Python2?
It sounds like your locale is broken and have another bytes->Unicode issue. The thing you did for Python 2.7 is a hack that only masked the real problem (there's a reason why you have to reload sys to make it work).
To fix your locale, try typing locale from the command line. It should look something like:
LANG=en_GB.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_ALL=
locale depends on LANG being set properly. Python effectively uses locale to work out what encoding to use when writing to stdout in. If it can't work it out, it defaults to ASCII.
You should first attempt to fix your locale. If locale errors, make sure you've installed the correct language pack for your region.
If all else fails, you can always fix Python by setting PYTHONIOENCODING=UTF-8. This should be used as a last resort as you'll be masking problems once again.
If Python is still throwing an error after setting PYTHONIOENCODING then please update your question with the stacktrace. Chances are you've got an implied conversion going on.
I had this issue when using Python inside a Docker container based on Ubuntu 18.04.
It appeared to be a locale issue, which was solved by adding the following to the Dockerfile:
ENV LANG C.UTF-8
To everyone using pickle to load a file previously saved in python 2 and getting an UnicodeDecodeError, try setting pickle encoding parameter:
with open("./data.pkl", "rb") as data_file:
samples = pickle.load(data_file, encoding='latin1')
For a Python-only solution you will have to recreate your sys.stdout object:
import sys, codecs
sys.stdout = codecs.getwriter('utf-8')(sys.stdout.detach())
After this, a normal print("hello world") should be encoded to UTF-8 automatically.
But you should try to find out why your terminal is set to such a strange encoding (which Python just tries to adopt to). Maybe your operating system is configured wrong somehow.
EDIT: In my tests unsetting the env variable LANG produced this strange setting for the stdout encoding for me:
LANG= python3
import sys
sys.stdout.encoding
printed 'ANSI_X3.4-1968'.
So I guess you might want to set your LANG to something like
en_US.UTF-8. Your terminal program doesn't seem to do this.
Python 3 (including 3.6) is already Unicode supported. Here is the doc - https://docs.python.org/3/howto/unicode.html
So you don't need to force Unicode support like Python 2.7. Try to run your code normally. If you get any error reading a Unicode text file you need to use the encoding='utf-8' parameter while reading the file.
for docker with python3.6, use LANG=C.UTF-8 python or jupyter xxx works for me, thanks to #Daniel and #zhy
I mean you could write an custom function like this:
(Not optimal i know)
import sys
def printUTF8(input):
print(input.encode("utf-8"))
I'm trying to understand if it is simply impossible to load a python module from a unicode path, or if there is some trick I am missing.
This bug report seems to imply that it is not possible:
http://bugs.python.org/issue11619
Goal:
suppose C:\Users\pkarasev\д contains Foo.py , then I want to do this:
import sys
sys.path.append(str('c:/Users/pkarasev/\xd0\xb3').decode('utf-8') )
from Foo import *
This fails with "cannot find module..." although u'c:/Users/pkarasev/\0433' has been added to my sys.path and 0433 is the correct encoding for д.
note that the str(...).decode(...) method works for things like os.open, but for some reason not for loading modules. Is there a different format for the encoding? Is this action impossible, period? Do I need to use python 3.x instead of 2.7.3 with some different syntax?
edit: cash award is eligible if someone knows a trick to do this (on windows)
Yeah it is either a bug in python for not supporting windows, or a bug in windows for not being sane and using utf-8 encoding. In python27.dll you can step in and see the bogus module paths...
So I have a python script calling some other pythons scripts in the working directory. I usually use naming conventions like v1.0.3_ModuleName.py to keep track of newer versus older versions of my script. When I tried to import my module:
import v1.0.3_ModuleName
I recieved the good ole: SyntaxError: invalid syntax error. Now I realized my error quickly and took out the periods.
This make me wonder, what other file names with result in errors when you try to import them into python?
If you're using linux you could make a symbolic link to your module that doesn't include dots and numbers :) But this isn't a portable solution.
More about module naming.
I recently wrote a Python 2.7 script (using PyDev on Eclipse) that took advantage of the built-in ConfigParser module, and the script works perfectly. But when I exported it and sent it to a colleague, he could not get it to work. He keeps getting an "unresolved import: ConfigParser" error even though we are using the exact same settings. This isn't supposed to happen as ConfigParser is built-in.
I've Googled everywhere but could not seem to find any working solution. Any help would be appreciated.
ConfigParser was renamed to configparser in python 3. Chances are he's using 3 and cannot find the old py2 name.
You can use:
try:
import configparser as ConfigParser
except ImportError:
import ConfigParser
To see what's happening it may be nice comparing on both computers which sys.path is being used (i.e.: put at the start of the module being run the code below and compare the output in each case):
import sys
print '\n'.join(sorted(sys.path))
Now, if the error is not when running the code (i.e.: it runs fine and you get no exceptions), and he gets the error only in PyDev, probably the interpreter configuration in his side is not correct and one of the paths printed through the command above is not being added to the PYTHONPATH (it could be that he's on a virtual env and didn't add the paths to the original /Lib or has added some path that shouldn't be there -- or even has some ConfigParser module somewhere else which is conflicting with the one from the Python standard library).