We Keep Coding

Fail to import tensorflow from a program called within a script via ssh [duplicate]

When I try to run my program from the PyCharm IDE everything works fine but if I type in Fedora:
python myScript.py
in a shell prompt I get an import error from 1 of the module.
ImportError : No modue named myDependency
What does PyCharm do that allows the interpreter to find my dependencies when launched from the IDE? How can I get my script to find its dependencies so it can be launched with a singe command?

There are a few possible things that can be causing this:
The same python interpreter? Check with import sys; print(sys.executable)
Is it the same working directory? Check with import os; print(os.getcwd())
Discrepancies in sys.path, which is the list python searches sequentially for import locations, can possibly caused by environment variables. Check with import sys; print(sys.path).

Adding this worked for me:
from os import sys, path
sys.path.append(path.dirname(path.dirname(path.abspath(__file__))))

As a first step, in PyCharm go to project settings / python interpreter, and note the path. Then compare that to the result of which python -- do they line up? If not, you need to make them do so.
If that's ok, check what PyCharm defines as your project root in project settings / project structure. Is that the directory where your script is located? If not, you should run the script from that directory or append the directory to the $PYTHONPATH variable.
Almost definitely, it's one of those two things.

You might have set some project dependency in Pycharm for module myDependency.
You can access the same in Fedora by importing the module explicitly or by creating the egg of that module and installing it.
This will then go to python site-packages from where you can refer this dependency.

Module Not found during import in Jupyter Notebook

I have the following package (and working directory):
WorkingDirectory--
|--MyPackage--
| |--__init__.py
| |--module1.py
| |--module2.py
|
|--notebook.ipynb
In __init__.py I have:
import module1
import module2
If I try to import MyPackage into my notebook:
import MyPackage as mp
I will get ModuleNotFoundError: No module named 'module1'. But import works fine if I execute the script outside a notebook: if I create test.py in the same directory and do the same as in the notebook the import would work properly. It will work inside the notebook if I use fully qualified name in __init__.py (import MyPackage.module1).
What's the reason for different import behavior?
I have confirmed the working directory of the notebook is WorkingDirectory.
---Update---------
Exact error is:
C:\Users\Me\Documents\Working Directory\MyPackage\__init__.py in <module>()
---> 17 import module1
ModuleNotFoundError: No module named 'module1'
My problem differs from the possible duplicate:
The notebook was able to find the package, but only unable to load the module. This was inferred from substituting module1 with MyPackage.module1 worked well and suggests it may not be a problem related with PATH.
I cded into WorkingDirectory and started the server there. The working directory should be the folder containing my package.

I'm pretty sure this issue is related and the answer there will help you: https://stackoverflow.com/a/15622021/7458681
tl;dr the cwd of the notebook server is always the base path where you started the server, no matter was running import os os.getcwd() says. Use import sys sys.path.append("/path/to/your/module/folder").
I ran it with some dummy modules in the same structure as you had specified, and before modifying sys.path it wouldn't run and after it would

understand this two functions, your problem will be solved.
#list the current work dir
os.getcwd()
#change the current work dir
os.chdir()
change the path, and import module, have fun.
sometime it won't work.try this
import sys
# sys.path is a list of absolute path strings
sys.path.append('/path/to/application/app/folder')
import file
-, -

if you face module not found on jupyter environment you had to install it on jupyter environment instead of installing it on command prompt
by this command(for windows) on jupyter
!pip install module name
after that you can easily import and use it.
Whenever you want to tell jupyter that this is system command you should put ( ! ) before your command.

The best way to tackle this issue is to create a virtual env and point your kernel to that virtual environment:
Steps:
python -m venv venv
source venv/bin/activate
ipython kernel install --user --name=venv
jupyter lab
go to the jupyter lab ->kernel-->change kernel-->add the venv from the dropdown
Now if your venv has the package installed, jupyter lab can also see the package and will have no problem importing the package.

You can do that by installing the import_ipynb package.
pip install import_ipynb
Suppose you want to import B.ipynb in A.ipynb, you can do as follows:
In A.ipynb:
import import_ipynb
import B as b
Then you may use all the functions of B.ipynb in A.

My problem was that I used the wrong conda enviroment when using Vs Code.
Enter your conda enviroment
conda activate **enviroment_name**
To check where a module is installed you can enter python interactive mode by writing python or python3. Then importing cv2
import cv2
Then to see where this module is installed
print(cv2.__file__)
You will see the installed path of the module. My problem was that my vs code kernel was set to the wrong enviroment. This can be changed in the top right corner for vs code.
hope this helps

this happened to me when I moved my journal into a new directory while the Jupyter lab server was running. The import broke for that journal, but when I made a new journal in the same directory I just moved to and used the same import, it worked. To fix this I:
Went to the root dir for my project.
Searched for all folders labeled “pycache”
Deleted all “pycache” folders that were found in my root and subfolders.
Restarted Jupyter lab server
Once Jupyter lab restarts and compiles your code, the “pycache” folders will be regenerated. Also the pycache folders have two leading and trailing “_”, but stackoverflow is formatting the pycache’s without them

The best solution by far (for me) is to have a kernel for each environment you are working in. Then, with that kernel defined, all you have to do is to update this kernel's environment variables to look at your project folder where your modules are located.
Steps (using pip):
pip install ipykernel (if not installed already)
source activate <your environment name>
python -m ipykernel install --user --name <your environment name> --display-name "<a display name>" (where is the name you want to give to your kernel and is just a name used for display by jupyter.
Once you ran the command above, it will output the location of the kernel configuration files. E.g.: C:\Users\<your user name>\AppData\Roaming\jupyter\kernels\<selected environment name>. Go to this folder and open the kernel.json file.
Add the following entry to this file:
"env": {
"PYTHONPATH": "${PYTHONPATH};<the path to your project with your modules>
}
Good reference about the kernel install command here.

The reason is that your MyPackage/__init__.py is ran from the current working directory. E.g. from WorkingDirectory in this case. It means, that interpreter cannot find the module named module1 since it is not located in either current or global packages directory.
There are few workarounds for this. For example, you can temporarily override a current working directory like this
cwd = os.getcwd()
csd = __path__[0]
os.chdir(csd)
and then, after all a package initialization actions like import module1 are done, restore "caller's" working directory with os.chdir(cwd).
This is quite a bad approach as for me, since, for example, if an exception is raised on initialization actions, a working directory would not be restored. You'll need to play with try..except statements to fix this.
Another approach would be using relative imports. Refer to the documentation for more details.
Here is an example of MyPackage/__init__.py that will work for your example:
from .module1 import *
But it has few disadvantages that are found rather empirically then through the documentation. For example, you cannot write something like import .module1.
Upd:
I've found this exception to be raised even if import MyPackage is ran from usual python console. Not from IPython or Jupyter Notebook. So this seems to be not an IPython itself issue.

How are modules are installed and located?

I need help to troubleshoot the installation of gspread for an GAE app.
On my Windows PC, I have python.exe in C:\python27.
I installed gspread by running its setup.py from its distribution folder as follows:
c:\python27\python.exe setup.py install --home=X
The following folder and files were created in X\lib\python:
request-2.9.1-py2.7.egg (a folder)
easy-install.pth
gspread-0.2.5-py2.7.egg
site.py
Why lib\python? Is this sub-folder hardcoded somewhere?
When I launch my Python interpreter, I can then import gspread. sys.path includes the fully qualified path to X\lib\python\gspread-0.2.5-py2.7.egg. Note it's a path to a file and not a folder.
How does Python know where to locate gspread? I tried looking in C:\python27 for clues but could not find anything related to gspread, not even in the site-packages folder.

Python searches sys.path in order. It is likely that Python is importing gspread using the contents of the egg. Note that if Python finds a match before the gspread egg, it will stop on the first matching entry in sys.path. For example if you have a module named gspread in the current working directory, then Python will not use the egg.
If you want to modify the package, you have many different options. I suggest to first uninstall the current egg. Then place the folder named gspread in site-packages.
An even better alternative is to add the gspread source directory to PYTHONPATH. You can change the PYTHONPATH environment variable by
My Computer -> Properties -> Advanced > Environment Variables

When you defined --home option setuptools is simulating linux Home directory thats why the installation location goes to X:\lib\python.
My guess is this home path is getting added to Python env on the system sorry I don't have windows to test this but there is some info here: https://docs.python.org/2.3/inst/alt-install-windows.html

PYTHONPATH conflict

I am trying to import ZipCodeDatabase in helloworld.py.
helloworld.py exists at /google-app-engine/helloworld
ZipCodeDatabase module exists /usr/local/lib/python/python2.7/dist-packages
PYTHONPATH = /usr/local/lib/python/python2.7/dist-packages;/usr/local/lib/python/
When compiling helloworld I am still getting "ZipCodeDatabase module not found". Why isn't it being picked from the PYTHONPATH?

I highly doubt you've got a module called ZipCodeDatabase. That naming convention is typically reserved for a class that resides within a module. Modules are usually lowercase or lower_snake_case, to represent the file containing the module. I'm assuming you've installed pyzipcode here, but it may be a different module.
# assuming pyzipcode.py in the dist-packages directory
$ python -c 'from pyzipcode import ZipCodeDatabase'
If I'm wrong above, then are you sure you're running the version of python that has the ZipCodeDatabase module installed?
Some troubleshooting steps:
$ which python
$ python --version
$ python -c 'import ZipCodeDatabase'
$ ls -l /usr/local/lib/python2.7/dist-packages/ | grep -i zip
Also, is it really necessary for you to specify the PYTHONPATH line? Typically, the site-packages folder (and by extension I assume the dist-packages folder on Ubuntu) is included in the default PYTHONPATH, along with the current directory of the python module you're using.
How did you install the ZipCodeDatabase? Did you just drop the file in there? Try putting it alongside your helloworld.py file and try importing it then. Also, a full stack trace is useful information here, especially when others are trying to diagnose the problem you're having.
Edit:
Ok, now that I know you're using google app engine (should have been obvious from your use of paths - I'm sorry), it looks like it doesn't use the site-packages or dist-packages to load modules. You should create a sub-directory in your project with the relevant third party libraries, and add that sub-directory to your path. Disclaimer: I've never used GAE so I might be missing the mark with this.
Check out this answer for how to structure your project and add the extra directory to your path from within the application.

Python: using downloaded modules

I am new to Python and mostly used my own code. But so now I downloaded a package that I need for some problem I have.
Example structure:
root\
externals\
__init__.py
cowfactory\
__init__.py
cow.py
milk.py
kittens.py
Now the cowfactory's __init__.py does from cowfactory import cow. This gives an import error.
I could fix it and change the import statement to from externals.cowfactory import cow but something tells me that there is an easier way since it's not very practical.
An other fix could be to put the cowfactory package in the root of my project but that's not very tidy either.
I think I have to do something with the __init__.py file in the externals directory but I am not sure what.

Inside the cowfactory package, relative imports should be used such as from . import cow. The __init__.py file in externals is not necessary. Assuming that your project lies in root\ and cowfactory is the external package you downloaded, you can do it in two different ways:
Install the external module
External Python packages usually come with a file "setup.py" that allows you to install it. On Windows, it would be the command "setup.py bdist_wininst" and you get a EXE installer in the "dist" directory (if it builds correctly). Use that installer and the package will be installed in the Python installation directory. Afterwards, you can simply do an import cowfactory just like you would do import os.
If you have pip or easy_install installed: Many external packages can be installed with them (pip even allows easy uninstallation).
Use PYTHONPATH for development
If you want to keep all dependencies together in your project directory, then keep all external packages in the externals\ folder and add the folder to the PYTHONPATH. If you're using the command line, you can create a batch file containing something like
set PYTHONPATH=%PYTHONPATH%:externals
yourprogram.py
I'm actually doing something similar, but using PyDev+Eclipse. There, you can change the "Run configurations" to include the environment variable PYTHONPATH with the value "externals". After the environment variable is set, you can simply import cowfactory in your own modules. Note how that is better than from external import cowfactory because in the latter case, it wouldn't work anymore once you install your project (or you'd have to install all external dependencies as a package called "external" which is a bad idea).
Same solutions of course apply to Linux, as well, but with different commands.

generally, you would use easy_install our pip to install it for you in the appropriate directory. There is a site-packages directory on windows where you can put the package if you can't use easy_install for some reason. On ubuntu, it's /usr/lib/pythonX.Y/dist-packages. Google for your particular system. Or you can put it anywhere on your PYTHONPATH environment variable.
As a general rule, it's good to not put third party libs in your programs directory structure (although there are differing opinions on this vis a vis source control). This keeps your directory structure as minimalist as possible.

The easiest way is to use the enviroment variable $PYTHONPATH. You set it before running your scripts as follows:
export $PYTHONPATH=$PYTHONPATH:/root/externals/
You can add as many folders as you want (provided their separate by :) and python will look in all those folders when importing.