After hearing Peter Wang talk about the Bokeh plotting environment, I had to try it. The problem is I can't even get the examples to work because I can't get the plot server going. I verified the install of all listed dependencies, and installed continuumweb (a module that is curiously absent from the list of dependencies in the Bokeh README on github). However, I still encountered the error below. It looks like this should come out of continuumweb, but I find no trace of such a sub-module within the repo. Am I looking in the wrong place? (I have not found any other instances of this exception.)
If anyone could provide some guidance, I would be grateful...
choct155#choct155-U46E:~/analysis/anaconda/pkgs/Bokeh$ python runserver.py
Traceback (most recent call last):
File "runserver.py", line 3, in <module>
from bokeh.server import start
File "/home/choct155/analysis/anaconda/pkgs/Bokeh/bokeh/server/start.py", line 76, in <module>
import services
File "/home/choct155/analysis/anaconda/pkgs/Bokeh/bokeh/server/services.py", line 4, in <module>
from continuumweb.launch_process import ManagedProcess
ImportError: No module named launch_process
Exception KeyError: KeyError(139639237560272,) in <module 'threading' from '/home/choct155/analysis/anaconda/lib/python2.7/threading.pyc'> ignored
For those who are reading this later, we've had two versioned releases since the original question, and they are all easy to install directly from PyPI via "pip install bokeh". If you are using Anaconda, it's even easier to install via "conda install bokeh".
For some reason, the pip installer did not perform well here. I just started from scratch by cloning the continuumweb repository and installing from source ('python setup.py install' in the cloned directory)...
All is well.
Related
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')
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!
I want to install Earth Engine API on Python on Ubuntu 18.04. I have both Python 2.7 and Python 3.6 installed on my system, and I install Earth Engine using both pip and pip3 as instructed (installing google-api-python-client, oauth2client, and earthengine-api) without any problem. But I get errors on both 2.7 and 3.6:
On Python 2.7, "import ee" works but "ee.Initialize()" returns this:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'Initialize'
On Python 3.6, "import ee" doesn't work and return this error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/sshahhey/.local/lib/python3.6/site-packages/ee/__init__.py", line 1, in <module>
from .main import main
File "/home/sshahhey/.local/lib/python3.6/site-packages/ee/main.py", line 10, in <module>
import StringIO
ModuleNotFoundError: No module named 'StringIO'
Any help? I am particularly interested in solving the problem for Python 3.
Following up on Kevin's answer:
I had this same issue, but the state of my /usr/local/lib/python2.7/site-packages/ee looked the same as that of my coworker, whose Earth Engine API was working fine. The issue is that there are 2 pip packages which write to the same directory:
earthengine-api:
this is the package you want
writes the Earth Engine library to site-packages/ee
ee:
Unrelated to EE, just a wrapper for dd
writes a main.py and __init__.py to site-packages/ee
The only difference between our two setups was the order in which we installed those packages. For me, installing ee second overwrote the __init__.py file, which prevented the ee module from importing the library contents. The fix was to completely clear out the directory and related dist-info dir, and start over:
rm -rf /usr/local/lib/python2.7/site-packages/ee
rm -rf /usr/local/lib/python2.7/site-packages/earthengine_api-0.1.182.dist-info
sudo pip install earthengine_api
It looks like your system has a Python package called ee which is not the Earth Engine API. I say this because the Python 3 traceback specifies a file named ee/main.py, which does not exist and never has. This would also explain why ee.Initialize() was not found in the other case.
I'd recommend going into /home/sshahhey/.local/lib/python3.6/site-packages/ee/ and browsing the code there to see what other package it might be. If it's not something you need, then you can just delete that ee/. If it is something you need for another purpose, you can use virtualenv to manage installations of conflicting libraries.
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.
I have installed requests on my mac, but the error message says the library does not exist. I have included "import requests" on line one of my Python script. I am using Python 3 for the call because it supports Server Name Indication, which I guess I need for this? Any pointers/help is greatly appreciated!
As you can see, I have installed requests:
Daves-MacBook-Pro:documents Dave$ pip install requests
Requirement already satisfied (use --upgrade to upgrade): requests in /Library/Python/2.7/site-packages
Cleaning up...
However when I try to run my script I get this error message:
Daves-MacBook-Pro:documents Dave$ python3 perka_call.py
Traceback (most recent call last):
File "perka_call.py", line 1, in
import requests
ImportError: No module named 'requests'
Try installing requests module for Python3. You have installed it for Python2.7
This might do the job.
pip install --target='/usr/lib/python3.4/' requests
I am assuming you are using python3.4