We Keep Coding

Installed Libraries are not being found by my IDE (Mac) [duplicate]

I am trying to import pyodbc module on a windows computer. It works in the terminal, but not the IDLE. The error message in IDLE is:
Traceback (most recent call last):
File "FilePath/Filename.py", line 3, in <module>
import pyodbc
ImportError: No module named pyodbc

This typically occurs when multiple versions of python are installed with different paths. You can check to see if you have multiple installations by opening up the IDLE terminal and using
import sys
sys.version
sys.path
These commands will print the system PATH and version of the current instance of python. Use this in both IDLE and the command line terminal to see where each differ. Once you know which version is the one you want then just remove the other. You could also remove all python instances and then reinstall a clean python environment but then you would have to re-install all of your modules using pip or easy_install

Open python in cmd (type python and press enter)
Import the module in cmd (type import modulename)
Type modulename.__file__
You will get the path where the module is stored
Copy the corresponding folder
In IDLE, import sys and typing sys.executable to get the paths where it looks for modules to import
Paste your module's folder in the path where IDLE looks for modules.
This method worked for me.

You can pip show after install package and know about location where package installed.
After that check in IDLE sys.path and if directory with package not in sys.path try to add it.
import sys
sys.path.append("/home/dm/.local/lib/python3.6/site-packages")
# or another folder that `pip show` about package.

this happen because of multiple python installed (32bit version, 64bit version) or 3v and 2.7v so to solve this problem you have to invoke the idle for that specific version like this
cd to the dir of the version that the import work fine in cmd in that folder type this command below
pythonw.exe Lib\idlelib\idle.pyw
this command will invoke idle for that version
and the import will work fine

Me too had the same issue while trying to import a module which was successfully imported on terminal and not able to install on IDLE.
How I fixed?
Assuming you know how to execute commands on terminal as well as inside of python interpreter
Open your Terminal & execute the below commands :
:~$ python3
Python 3.6.9 (default, Jan 26 2021, 15:33:00)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>
>>> import sys
>>> sys.version
'3.6.9 (default, Jan 26 2021, 15:33:00) \n[GCC 8.4.0]'
>>> sys.path
['', '/usr/lib/python36.zip', '/usr/lib/python3.6',
'/usr/lib/python3.6/lib-dynload', '/usr/local/lib/python3.6/dist-
packages', '/usr/lib/python3/dist-packages']
>>>
Now import your module inside of your python3 interpreter.
>>> import nester
>>>
>>> nester.__file__
'/usr/local/lib/python3.6/dist-packages/nester.py'
>>>
Open your IDLE and run the below commands and compare them
Python 3.9.1 (tags/v3.9.1:1e5d33e, Dec 7 2020, 17:08:21) [MSC v.1927
64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more
information.
>>> import sys
>>> sys.version
'3.9.1 (tags/v3.9.1:1e5d33e, Dec 7 2020, 17:08:21) [MSC v.1927 64 bit
(AMD64)]'
>>> sys.path
['','C:\Users\username\AppData\Local\Programs\Python\Python39\Lib\idlelib', 'C:\Users\username\AppData\Local\Programs\Python\Python39\python39.zip', 'C:\Users\username\AppData\Local\Programs\Python\Python39\DLLs', 'C:\Users\username\AppData\Local\Programs\Python\Python39\lib', 'C:\Users\username\AppData\Local\Programs\Python\Python39', 'C:\Users\username\AppData\Local\Programs\Python\Python39\lib\site-packages']
>>> sys.executable
'C:\Users\username\AppData\Local\Programs\Python\Python39\pythonw.exe'
Now if you compare both outputs from Terminal & IDLE,
Terminal Module location is different from IDLE
I was using Ubuntu 18 terminal on windows machine
So I just copied my file to 'C' directory and ensured its file privileges. That's it.
:~$ cp -p /usr/local/lib/python3.6/dist-packages/nester.py /mnt/c/Users/username/AppData/Local/Programs/Python/Python39/Lib/
It worked!!

I Found the solution. It works for me
The problem is your installation directory does not match with the python version directory.
solution is >>>
type %localappdata% in your search bar then go to this folder.
here select the program folder. then select Programs , Python , Python version , Scripts
copy the location of the Scripts folder
open command prompt and type cd //yourpath (in my case cd C:\Users\3C HOUSE\AppData\Local\Programs\Python\Python37\Scripts)
if you wanna install numpy , now run pip install numpy

When you put your python scripts that have import pandas in the same folder as the site packages like pandas for example and use the same version of python that is used on CMD, it should help run your scripts in IDLE.

Check the path of your code, and that of the module. Copying the module to the path where code is worked for me.
'sys.executable' will give the path where code is stored.

For windows, open command prompt and enter pip show pyodbc to get the path of package and copy the path.
then open idle and run these lines
import sys
sys.path
Match the path from command prompt and the paths mentioned in the list provided by running above lines in IDLE. If the path is not mentioned then run these lines in idle
sys.path.append("Enter the copied path of package here")
After executing these lines, check again by importing the package that if it works for you.

from google.cloud.logging_v2 import types ImportError: cannot import name types

I'm working on a small app running on GAE. When I deploy my application or try and use virtualenv (per the docs), I see the following in the logs in Cloud Platform (they're the same locally, too) when I try and access the app:
File "/base/data/home/apps/d~my-project/gen-debug:413039252702584887/main.py", line 10, in <module>
from google.cloud import logging_v2
File "/base/data/home/apps/d~my-project/gen-debug:413039252702584887/lib/google/cloud/logging_v2/__init__.py", line 17, in <module>
from google.cloud.logging_v2 import types
ImportError: cannot import name types
My code that's throwing this error looks like this:
from google.cloud import logging_v2
client = logging_v2.LoggingServiceV2Client()
c = client.list_log_entries(["my-project"], filter_='resource.type="global" AND jsonPayload.hello="there"')
l = list(c)
l1 = l[0]
desc, value = l1.ListFields()[1]
print desc.camelcase_name, dict(value.items())
The thing that is so freaking weird is that in Google, I can go into a Cloud Shell session, get into ipython, and this code totally works.
me#cloudshell:~ (my-project)$ ipython2
Python 2.7.13 (default, Sep 26 2018, 18:42:22)
Type "copyright", "credits" or "license" for more information.
IPython 5.8.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: from google.cloud import logging_v2
...: client = logging_v2.LoggingServiceV2Client()
...: c = client.list_log_entries(["my-project"], filter_='resource.type="global" AND jsonPayload.hello="there"')
...: l = list(c)
...: l1 = l[0]
...: desc, value = l1.ListFields()[1]
...: print desc.camelcase_name, dict(value.items())
...:
jsonPayload {u'hello': u'there'}
What's going on that makes running this on GAE different than running it in the Google Cloud Shell? This import error seems like a Google issue, but I'm not sure.

That looks like the generic python client for Stackdriver logging. Which isn't designed for/supported on GAE first-generation (i.e., Python 2.7) apps as this runtime already has it's own (customized) stackdriver logging integrated.
From Supported environments:
The following VM instances support Stackdriver Logging using their own
software, possibly including custom versions or configurations of the
Stackdriver Logging agent. Manually installing the Stackdriver Logging
agent on them is not supported:
App Engine standard environment VM instances. App Engine includes built-in support for Stackdriver Logging. For more
information, see Stackdriver Logging in App Engine Apps.
App Engine flexible environment VM instances. Apps running in the App Engine flexible environment can write logs that are in
addition to what is included in the App Engine standard environment.
For more information, see Stackdriver Logging and the App Engine
flexible environment.

Changing PYTHONHOME causes ImportError: No module named site

I am trying to deploy a Flask web app via mod_wsgi on Apache. I cannot use the default Python environment because it was compiled with UCS-2 Unicode instead of UCS-4, and I cannot recompile it for this one case. Thus, a virtual environment. Virtual environments would have been used anyway, but that error means that I can't get away with using the default Python install and just adding the virtual environment's modules to the PYTHONPATH, which otherwise would have let me avoid the current problem entirely by accident.
I found the documentation for mod_wsgi to change which Python executable to use. However, when attempting to do so, the server fails to work properly. /var/log/httpd/error_log rapidly floods with the line ImportError: No module named site.
I have checked every similar question I can find here and elsewhere, and not yet had success. Experimentation has shown that as far as I can tell, the problem occurs when changing PYTHONHOME without activating a virtual environment - and the way the automated deployment works (via Fabric), as far as I can tell I can't activate a virtual environment.
Apache config
My current httpd.conf for the app:
WSGIPythonPath /path/to/dir/containing/wsgi/file/and/app:/path/to/virtualenv/lib:/path/to/virtualenv/lib/site-packages
WSGIPythonHome /path/to/virtualenv
WSGISocketPrefix /var/run/wsgi
User user
Group group
<VirtualHost *>
ServerName servername.generic.com
DocumentRoot /path/to/dir/containing/wsgi/file/and/app/static_dev/
WSGIDaemonProcess appname user=user group=group threads=2
WSGIScriptAlias / /path/to/dir/containing/wsgi/file/and/app/app.wsgi
<Directory /path/to/dir/containing/wsgi/file/and/app>
WSGIProcessGroup appname
WSGIApplicationGroup %{GLOBAL}
Require all granted
</Directory>
</VirtualHost>
Data I've found from failed attempts
I know that the error is not in my app.wsgi, because when I added the line raise Exception('tried to open the file') at the very top to check that, the existing ImportError kept happening instead of that new Exception.
I have confirmed via ldd that my version of mod_wsgi is for Python 2.7.
I have tried setting WSGIPythonHome /path/to/virtualenv/bin/ and WSGIPythonHome /path/to/virtualenv/bin/python, with the same result as the current state.
I have tried omitting the WSGIPythonHome directive, in which case it loads the app.wsgi as it should, but breaks on a later import as described at the top (the reason I can't just do that).
I have tried omitting the WSGIPythonPath directive and leaving it up to app.wsgi to add things to the PYTHONPATH, with the same result as the current state.
I have tried putting the path-setting as an argument to WSGIDaemonProcess instead of as the WSGIPythonPath directive, with the same result as the current state.
I have confirmed that there is a site.py in /path/to/virtualenv/lib.
I have confirmed that no other non-app-specific Apache .conf files being used (default settings, automatic module loads, etc) contain the string "WSGI", so I don't think there's any conflicts here.
If I activate the virtual environment from the command line I can import site without an error, just for the sake of testing that it does in fact exist in the environment. However, this is insufficient because it needs to start smoothly from a single call to sudo systemctl start httpd.service due to the deployment tools in use, and that seems to not care about the venv of the current shell session.
If, from a default state, I export PYTHONHOME=/path/to/virtualenv, attempting to open the Python REPL exits immediately with ImportError: No module named site.
If I activate the virtual environment and then set PYTHONHOME, I get the same import error.
If I activate the virtual environment and don't touch PYTHONHOME, echo $PYTHONHOME outputs a blank line, and the Python REPL works fine. In the Python REPL while in the virtualenv:
(virtualenv)-bash-4.2$ python
Python 2.7.8 (default, Aug 14 2014, 13:26:38)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/path/to/virtualenv'
>>> sys.exec_prefix
'/path/to/virtualenv'
Even though setting PYTHONHOME to the same value didn't work.
If I try export PYTHONHOME=:/path/to/virtualenv or export PYTHONHOME=/path/to/virtualenv:, explicitly setting only one of prefix and exec_prefix, it fails with the same import error in either case.
If I activate the virtual environment and set PYTHONHOME in one of those latter two ways, the unset one appears to default to / rather than to the usual default value, but the Python REPL runs fine:
# Setting only exec_prefix
(virtualenv)-bash-4.2$ export PYTHONHOME=:/path/to/virtualenv
(virtualenv)-bash-4.2$ python
Python 2.7.8 (default, Aug 14 2014, 13:26:38)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/'
>>> sys.exec_prefix
'/path/to/virtualenv'
>>> quit()
# Setting only prefix
(.virtualenv)-bash-4.2$ export PYTHONHOME=/path/to/virtualenv:
(.virtualenv)-bash-4.2$ python
Python 2.7.8 (default, Aug 14 2014, 13:26:38)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/path/to/virtualenv'
>>> sys.exec_prefix
'/'
Unfortunately, since the deployment script doesn't care what environment is activated, that doesn't solve it. Trying to set WSGIPythonHome in such a fashion makes no difference whatsoever.
I have noticed one further thing: The Python in the virtualenv is 2.7.8. The Python run outside the virtualenv (usr/bin/python) is 2.7.5. I do not know - would this affect the setting of PYTHONHOME somehow? I would hope not - since that seems to defeat the entire purpose of using WSGIPythonHome to run a virtualenv as compared to just setting sys.path inside the app.wsgi file, the ability to start from a different executable - but I cannot rule it out, clueless as I am.
The 2.7.8 Python in /path/to/virtualenv/bin/python has a sys.real_prefix of /network-mounted-drive/sw/python/python-2.7.8.
I changed the deployment to build from /network-mounted-drive/sw/python/python-2.7.5, then did more tests. Results as follows:
Attempting to start httpd gives the same import error as before.
Setting PYTHONHOME to the location of the virtual environment, then running python:
-bash-4.2$ echo $PYTHONHOME
/path/to/virtualenv
-bash-4.2$ python
ImportError: No module named site
Setting PYTHONHOME to the location of the virtual environment, then explicitly running the virtual environment's python binary (activating the virtual environment and then running python gives the same result):
# In the directory just above the virtualenv
-bash-4.2$ ./virtualenv/bin/python
Python 2.7.5 (default, Mar 14 2016, 14:13:09)
[GCC 4.8.3 20140911 (Red Hat 4.8.3-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/path/to/virtualenv'
>>> sys.exec_prefix
'/path/to/virtualenv'
>>> sys.real_prefix
'/network-mounted-drive/sw/python/python-2.7.5
Does anyone have any idea?

Resolution found: The issue seems to have been in trying to use a virtual environment built from something other than the local python install on the system.
Solved by pushing the problem of "local python install on the deployment VM doesn't have pip installed" up the chain to someone with the permissions required to install pip, since no attempted workarounds via networked python installs worked.
The issue of actually using a virtual environment chained from a Python install on a network drive for mod_wsgi may be insoluble, or at least I couldn't figure it out in a reasonable amount of time relative to the bureaucratic solution.

PyLint not finding class from Google Appengine SDK

We have a Python Application running on Google App Engine. For local development, we have the Google Appengine SDK installed. The setup is a little messed up as the application itself adds things to the sys.path. PyLint of course does not pick up those changes happening somewhere in some function.
I tried cleaning up the PyLint log by adding the Google Appengine SDK to the PYTHONPATH, which worked pretty good. Locally, I can now run PyLint for a specific set of folders and it reports a 10/10 with no errors (but a lot of locally-disabled statements). The same code is reporting exactly 1 issue on our CI system (We use Codeship). The message is Module 'google.appengine.ext.ndb' has no 'JsonProperty' member (no-member).
The Googe Appengine SDK is installed inside the Codeship container and is added to the PYTHONPATH. Other functions/classes from the SDK get picked up correctly. The google.appengine.ext.ndb.init.py looks like this:
"""NDB -- A new datastore API for the Google App Engine Python runtime."""
__version__ = '1.0.10'
__all__ = []
from tasklets import *
__all__ += tasklets.__all__
from model import * # This implies key.*
__all__ += model.__all__
from query import *
__all__ += query.__all__
from context import *
__all__ += context.__all__
The google.appengine.ext.ndb.model.py contains the JsonProperty class and has some magic as well:
# Update __all__ to contain all Property and Exception subclasses.
for _name, _object in globals().items():
if ((_name.endswith('Property') and issubclass(_object, Property)) or
(_name.endswith('Error') and issubclass(_object, Exception))):
__all__.append(_name)
As I said, it works locally but does not on Codeship. Locally, `pylint --version prints
pylint 1.5.0,
astroid 1.4.5
Python 2.7.9 (default, Apr 2 2015, 15:33:21)
[GCC 4.9.2]
while on Codeship, it says
pylint 1.5.0,
astroid 1.4.4
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2]
I am not sure what is going on here. There should be no major differences between Python 2.7.6 and 2.7.9, right? I have no idea how to further debug this either. Any hints are appreciated.

Can't import the cx_Oracle module unless I'm using an interactive shell

When using Python on an interactive shell I'm able to import the cx_Oracle file with no problem. Ex:
me#server~/ $ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
>>>
As you can see, importing works without a hitch. However, when I try to run a Python script doing the same thing, I get an error:
me#server~/ $ sudo script.py
Traceback (most recent call last):
File "/usr/local/bin/script.py", line 19, in <module>
import cx_Oracle
ImportError: No module named "cx_Oracle'
Here is the important section from script.py:
# 16 other lines above here
# Imports
import sys
import cx_Oracle
import psycopg2
...
I'm befuddled here. Other pertinent information is the server I'm running is Ubuntu 14.04.1 LTS (upgraded from 12.04) 64bit. which python and sudo which python both point to the same location. Also, doing this as root via sudo su - gets the same results; import OK from interactive but error from script.
Nothing other than the OS upgrade happened between when this worked and when it stopped working.

Sorry, all. This was a silly on my part. Turns out the script in question was using Python3, and when the server upgraded, Python3 went from being 3.2 version to being 3.4 version.
Once the cx_Oracle module was set up in the 3.4 version, everything worked as expected.
Phil, your final note talking about the shebang was what lead me to discover this, so kudos to you! The reason I didn't mark your response as the answer was because technically it wasn't but led me on the right path.
Cheers!

sudo starts a new bash environment which is then pointing to a different python executable (different installed modules).
You can verify this with which python and sudo which python
EDIT: so if they point to the same executable, then you should look at sys.path to find differences. In both environemnts you can:
python -c "import sys; print('\n'.join(sys.path))"
sudo python -c "import sys; print('\n'.join(sys.path))"
Look for differences. If there are none:
A common error in import situations like this is that python will first look at the local dir. So if you happen to be running python and importing something what is found locally (i.e. cx_Oracle is a subdir of your current location), you will get an import error if you change directories.
Final note: I have assumed here that the shbang of the script.py points to the same executable as which python. That is, that python script.py and script.py return the same error.