PyInstaller ImportError - pyinstaller

I have been experimenting with PyInstaller for a few days. My operating system is FreeBSD 10.4 and I use Python 3.6. When I issue this command from the terminal, it works all fine:
# pyinstaller my_script.py
But this command has an unprecedented side effect. When I write this:
if __debug__:
print("debug")
I get "debug" printed to the console, which suggests that PyInstaller compiles the script with debug symbols.
While searching for a solution to this problem, I found that running PyInstaller through the Python interpreter with the -O parameter would solve the problem:
[root#bsd-pwb ~]# /usr/local/bin/python3.6 /usr/local/lib/python3.6/site-packages/PyInstaller/__main__.py my_script.py
But this time, I get this:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/PyInstaller/__main__.py", line 21, in <module>
from . import __version__
ImportError: cannot import name '__version__'
What am I doing wrong here? How can I get PyInstaller to compile with "debug" set to "False"?

I recommend you trying your script exactly as it is but using a Python 3.5 Enviroment, there are so many publications where you can realize that pyinstaller is more stable with python 3.5 versions than 3.6. I had several errors as the one you are commenting and at the end they get solved just running my scripts on python<=3.5

From the docs you can actually get it working by using another method: set explicitely the PYTHONOPTIMIZE environment variable to a non-zero value, in your case:
PYTHONOPTIMIZE=1 pyinstaller myscript.py

Related

'cfgrib' is not showing in xarray engine list, when the python code is packaged with pyinstaller to get exe file

I am trying to create an executable file from python code with 'Pyinstaller' package. The code runs in conda environment where the cfgrib selfcheck is good:
Found: eccodes v2.27.0.
your system is ready
However when the executable created by pyinstaller runs, the error is:
ValueError: unrecognized engine cfgrib must be one of: ['scipy','store']
I adde 'eccodes', 'python-eccodes', 'cfgrib', 'netcdf4' to the hidden imports, but no success. Does anybody have any idea to fix this issue!

using hydra with pyinstaller

I have been trying to use Hydra with PyInstaller and failed.
I have created a very configuration example similar to example in here.
I noticed that hydra packages are not being found by PyInstaller so I created a simple hook file hook-hydra.py with the following code:
from PyInstaller.utils.hooks import collect_data_files, collect_submodules
datas = collect_data_files('hydra')
hiddenimports = collect_submodules('hydra')
That seemed to solve the module imports failures, but then when I tried to run the executable in the command line I got the following error:
Traceback (most recent call last):
File "lib\site-packages\hydra\_internal\utils.py", line 198, in run_and_report
File "lib\site-packages\hydra\_internal\utils.py", line 321, in <lambda>
File "lib\site-packages\hydra\_internal\hydra.py", line 74, in create_main_hydra2
File "lib\site-packages\hydra\_internal\config_loader_impl.py", line 80, in __init__
File "lib\site-packages\hydra\_internal\config_repository.py", line 22, in __init__
File "lib\site-packages\hydra\_internal\sources_registry.py", line 30, in resolve
ValueError: No config source registered for schema pkg, supported types : []
I can't seem to figure it out, any ideas?
I'm using PyInstaller 3.6 and Hydra 1.0.4
After taking a look at PyInstaller, it looks like it's attempting to discover needed packages and it somehow fails to do a good job for Hydra.
Hydra has some built in plugins that are discovered at runtime, including the config sources. The error suggests that the config sources were not packages by PyInstaller.
If PyInstaller is trying to be clever and only include things it sees a direct dependency on it is likely to fail for Hydra.
Try to add all hydra modules explicitly to your PyInstaller config file.
As an alternative packaging method for your app, take a look at the application packaging example here. It shows you the supported method for installing Hydra apps (with a working example).
Hydra does not play nice with PyInstaller because it dynamically reads the plugin packages using pkgutil.walk_packages.
Check out the issue and answers here: Pyinstaller - include programmatically imported modules
As you are not solving this from a library developer's point of view, copying the package using the data field in the .spec file could solve your issue, although it is a bit hacky. Either this or switching to OmegaConf is a good solution in my opinion.
I faced similar issues and ended up having to create a pyinstaller hook named hook-hydra.py and put it in the pyinstaller hooks folder. It could probably be reduced to lower level hydra namespaces. Leveraging other hooks, I did the following:
Only issue I face is inline using compose overrides=[f"environment.root_path={set_root_path}"], complains about EOF .... etc. But have workaround for that. Logging and Fetching configuration works like a charm.
from PyInstaller.utils.hooks import collect_submodules
# Use this to get hydra internals
# "hydra._internal.core_plugins"
# "hydra.plugins"
# 'hydra._internal.core_plugins','hydra.grammar.gen.OverrideParser'
hiddenimports = collect_submodules('hydra')
This works for me, no problems running from command line, using PyInstaller 4.5.1, Hydra 1.2:
from PyInstaller.utils.hooks import collect_data_files, collect_submodules
datas = collect_data_files('hydra', subdir='conf')
hiddenimports = collect_submodules('hydra')

Symfony along with NLTK

I have a script in Python that imports out of some other packages, the NLTK package.
The OS is Debian Stretch. Executing it directly on Linux everything works as should it be. But running the mentioned script with Sympony - Process, it returns the following error:
Traceback (most recent call last):
File \"/var/www/html/public/_import.py\", line 1, in <module>
import nltk
ModuleNotFoundError: No module named 'nltk'
If simply I just comment "import nltk", all the script works properly even with Symfony Process at all.
I could not leave this problem, as I have resolved it, without an answer for you that might be facing the same issue!
The problem at all was not caused by Symfony - Process, but, unfortunatly, by instalation behavior of the module named: "NLTK";
In my case, the user used to install things on Linux Debian Stretch was the root.
Try (now, you, before changes and check...) to use the following command in your terminal: pip show nltk.
The output is:
Name: nltk
Version: 3.4.5
Summary: Natural Language Toolkit
Home-page: http://nltk.org/
Author: Steven Bird
Author-email: stevenbird1#gmail.com
License: Apache License, Version 2.0
Location: /usr/local/lib/python3.7/site-packages
Requires: six
Required-by:
Take a look at Location. Now it is the right place. But, as default, pip install nltk will place it, in my case with user "root" installing things, at "/root/.local/lib/python3.7/site-packages/nltk" as the base path! So, when the user "www-data" tried to runing it... ModuleNotFoundError: No module named 'nltk'
No module named 'nltk' - because it was not there to the place should it be accessed!
So, as you might guess now, the problem as caused by permission issues! Unfortunatly, no error (logs) output happened that would drive me to mind that would it be related to permission issues!
The solution:
1) Not messing around with the system or executing unecessary changes was considered at first place;
2) Had uninstalled it with pip the module NLTK and I have seeked to find where the other modules were installed;
3) Installed it (NLTK) again, but now, placing it where I want, I mean, where it should be since the begening: among the others modules - as numpy -, that could be accessed easily and without issues!
The command used was:
pip install --target="/usr/local/lib/python3.7/site-packages"
--upgrade nltk
Now, NLTK resides at /usr/local/lib/python3.7/site-packages followed by all the other modules working properly like a charm!
I hope this helps you!

Openmdao: Not able to use gradient free approaches. eg: NSGA2

I am working on windows platform and have set up all my requirements for NSGA2 solver but still it is not working. I have downloaded and installed MPI, MinGW, SWIG, Pyopt, pyoptsparse but still I am unable to use the pyoptsparse driver.
If someone could help on this, it will be of a great help. Thanks
I have pasted the error below
D:\Anaconda2\Scripts\python.exe D:/OpenMDAO/Mitul/Sellar/Sellar_MDF.py
Traceback (most recent call last):
File "D:/OpenMDAO/Mitul/Sellar/Sellar_MDF.py", line 6, in <module>
from openmdao.drivers.pyoptsparse_driver import pyOptSparseDriver
File "d:\anaconda2\lib\site-packages\openmdao\drivers\pyoptsparse_driver.py", line 19, in <module>
from openmdao.core.driver import Driver
File "d:\anaconda2\lib\site-packages\openmdao\core\driver.py", line 15, in <module>
from openmdao.util.options import OptionsDictionary
ImportError: No module named options
it is difficult to get MPI and pyopt-sparse built correctly on windows. But It has been done successfully. You can see the docs here for detailed instructions
That being said... there is clearly something wrong with your OpenMDAO installation. That error implies that things are not being copied correctly into the installation folder. Since you're using anaconda, I suggest that you create a new anaconda env as follows:
conda create --name om2 python=2 numpy scipy matplotlib
then activate it with source activate om2 and try to re-install openmdao via pip. You can get the very latest by doing
pip install git+http://github.com/OpenMDAO/OpenMDAO.git#master
Once you've done that, before you try to get mpi/petsc/pyopt-sparse installed you should run our test suite. Follow our docs on that, and if the tests all pass you can move on to the other more advanced install steps.

Spyder not recognizing splinter

Though splinter is installed on my Windows Vista, spyder gives an error when I import it.
When I import in windows command prompt, it successfully imports & also shows path to the init file.
Have added explicit path in PYTHONPATH Manager of Spyder and Updated module list. Yet, did not help.
Have checked my PATH environment variable. It contains the path to Python, Python/Scripts & Python/Lib/site-packages. PATH contains no spaces and PATH is indeed named as PATH & not as Path (probably thats why able to import successfully via command prompt)
When I try to install splinter again (just to confirm if it exists or not), pip says it already exists. When I try to upgrade, pip says it is already up-to-date
Have read lots & lots of articles on stackoverflow & across the web, but no solution helped.
Spyder recognizes other packages like os, numpy, etc.
Had run this code successfully on a temporary testing machine. Now trying to run on my system and its failing with error ImportError: No module named 'splinter'
Python ver. 3.4; Spyder ver. 3.4
Hoping for a solution...
Complete trackeback:
runfile('E:/Rampy/DS/Python/Code/AGMARK.py', wdir='E:/Rampy/DS/Python/Code')
Traceback (most recent call last):
File "", line 1, in
runfile('E:/Rampy/DS/Python/Code/AGMARK.py', wdir='E:/Rampy/DS/Python/Code')
File "C:\Users\ramprasad.g\AppData\Local\Continuum\Anaconda3\lib\site->packages\spyderlib\widgets\externalshell\sitecustomize.py", line 580, in runfile
execfile(filename, namespace)
File "C:\Users\ramprasad.g\AppData\Local\Continuum\Anaconda3\lib\site->packages\spyderlib\widgets\externalshell\sitecustomize.py", line 48, in execfile
exec(compile(open(filename, 'rb').read(), filename, 'exec'), namespace)
File "E:/Rampy/DS/Python/Code/AGMARK.py", line 8, in
from splinter import Browser
ImportError: No module named 'splinter'
Okay. So, I could make it work with a work-around.
Inspite of adding C:\Python34 & its Lib (site-packages) folder to PATH environment variable and Spyder's Python Path Manager, it failed to recognize splinter package while running the code in Spyder. So, I copied & pasted Splinter (followed by Selenium) package-folders from C:\Python34\Lib\site-packages (location where PIP installed the packages) to C:\Users\ramprasad.g\AppData\Local\Continuum\Anaconda3\Lib\site-packages (Anaconda's package location which alone Spyder seems to recognize) and boom! It started working!

Resources