Python in terminal finds module, jupyter notebook does not

Hi, I am in a situation where python, in a terminal, finds a module with “import”. In fact, with
“print(help(‘modules’)”
I see a list of all available modules, and the module in question is listed.

However, when running a jupyter notebook, of the proper version of python, I always get “module not found”.

One think that I would like to do is to find out exactly where the module in question is being stored and then append that path to the path where the notebook is looking. But, I don’t know how to find the module path.

Is there another way to go about this?

Thank You
Tom

Does the terminal you get from the Jupyter Dashboard allow import? Or are you talking about your terminal software on your computer?

Thank you for the reply. Yes, the terminal that I am referring to is from the jupyter dashboard. I would have expected that the terminal and the notebook would be looking in the same place, which, I believe they do.

Here is the result of “sys.path” in the terminal
[’’, ‘/usr/lib/python36.zip’, ‘/usr/lib/python3.6’, ‘/usr/lib/python3.6/lib-dynload’, ‘/usr/local/lib/python3.6/dist-packages’, ‘/u
sr/lib/python3/dist-packages’]

Here is the result of sys.path in the jupyter notebook.
[’’,
‘/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’,
‘/usr/lib/python3/dist-packages/IPython/extensions’,
‘/root/.ipython’,
‘~/jupyter_notebooks/BNN-PYNQ’,
‘~/jupyter_notebooks/BNN-PYNQ/bnn’]
(I added the last two entries manually).

If I had to guess I would think that it was an issue between the kernel that the notebook was executing and the version of python that the terminal was using. I do have to specifically invoke python3.6 in the terminal in order for python to find the module. Python2.7 is the default, which does not find the module.

The result of “print(python_version())” in the notebook is 3.6.5. So I know that it is not running 2.7

Tom

If you dont find module, it means that terminal and jupyter notebook are in different environments.
I saw the sys.path:

‘/usr/local/lib/python3.6/dist-packages’,
‘/usr/lib/python3/dist-packages’,

It’s just my guess. Could you show more info about your envrionment.

No clue here really, but does this also happen if you open your terminal from different directories? If the module is available in directly in the current dir, that might make it succeed.

Yes, I think @00Kai0 is on the right track. However, I don’t know what to tell you to fix it at this point.
When I was switching locally between 2.7 and Python 3, I ran Python 3 and JupyterLab via virtualenv in the hopes of avoiding things like this.
In case you can opt to not be confined to your local machine, this is one of the many reasons I prefer to work remotely with either MyBinder.org or cloud computers or PAAS. I’d be happy to share more information about those with you if that is an option or if no one can save you easily, and you don’t want to move to using a virtualenv locally.

00Kai0,
Thank you for your reply.

My environment? Well, I am sure that you mean something very specific. I would be happy to provide you information of a specific nature.

In general, I am running ubuntu 16.04, but the jupyter notebook is running on a xilinx based development board. The Ultra96V2. I can open up terminals on the development board.

According to the documentation for this project, which I got here https://github.com/Xilinx/BNN-PYNQ/

this project was supposed to run once I logged in via a browser after establishing a wireless link, which I have done.

Yes, I can see a number of jupyter notebooks. When I attempt to run one from the browser, I have issues.

What I did was to open up a terminal and convert the ipynb file to a py file. By running the py file I am now able to get most of the project to work. So, I can establish that the hardware on the development system is functional to this point. I got it to work by moving the file in question to a higher level in the directory tree, than was mentioned. This, to me, is a clue but I can not determine what the clue means. By moving the .py file to a higher directory I was able to determine that it could “find” the module in question that it was “barfing” on before (that is a technical term).

However, I did the same thing for the .ipynb file (moving it up to a higher directory) and yes, it found the module in question but the python kernel “hangs” at a certain point, whereas it did not in the .py execution of the project.

So, I am sure that changing the directory is only a partial solution. Where to go from here I am not sure.

Please ask for any specific information that you want.

Thank You

Tom

However, the

2 Likes