How does Jupyter find modules? - ipython

I'm trying to troubleshoot an issue where my Jupyter Notebook can't find an installed module, and I'm surprised that I can't find this basic information anywhere in the documentation. How do I specify where any given instance of Jupyter Notebook should look for modules?
A possibly related question: When I use jupyter --path, I see a listing of directories under the "data" heading. Is this where Jupyter looks for modules, and if so, what file do I edit to change it?
Edit I'm starting to understand, and I think I asked the wrong question. Jupyter loads a Python interpreter, and the interpreter is what deals with modules. How a Python interpreter finds modules is well-covered territory, but I still don't understand the first part. So, I should have asked, "How does Jupyter determine which Python executable to use?"

Related

Run Julia from remote using Jupyter locally

I apologize if it is a trivial question, but I searched and I could not find the answer. My situation is the following:
I have access to a server through ssh tunnelling. The server has Julia installed but not jupyter.
My machine has both, and my code is mostly in jupyter notebooks and I wish to keep it that way.
I wish to be able to run my code on a julia kernel on the server, but editing from a Jupyter interface/ IJulia locally.
I have found several guides on how to launch jupyter from remote, but they do not apply since the server does not have jupyter installed. Similarly, I am aware I could convert my code in a julia script and run it, but I would rather keep the convenience of a notebook for editing.
Is this even possible to do?
Any help is very appreciated!

How can I enable file path autocompletion in the IPython console in PyCharm?

Note: The suboptimal autocompletion (not necessarily of file paths only, but autocompletion in general) is a known issue, and there seems to be no generic quality solution yet. Please see the researched links below.
Path autocompletion in the IPython console in PyCharm does not work well:
c:/U<TAB>
should autocomplete to:
cd c:/Users/
on my machine; instead, the best it manages is:
cd c:/UserWarning
which is plain wrong. IPython in the Anaconda prompt, however, behaves as it should.
My strong assumption (supported by a link, below) is that this is due to PyCharm not using the standard IPython configuration files.
I'm aware of the console starting script in PyCharm:
Settings->Build, Execution, Deployment->Console->Python console
and I've successfully used it to activate a simple magic command I've written.
So here my question: is there a code configuration snippet that could be inserted there, and that could just enable file path autocompletion? Or a pointer to a general description on how IPython configuration files "work", that would enable me to figure it out myself? That is, I imagine, the most doable hack that would solve the problem for the time being.
Alternatively, any experiences with writing your own autocompletion using the following libraries:
IPython.core.completer
IPython.core.completerlib
?
Is that doable? How much work can that be?
Thanks in advance!
My SW-Setup:
I use:
PyCharm Community Edition 2017.2.1
Anaconda 2 (Python 2.7), version 4.3.22 which contains
IPython 5.1.0
on Windows 7 Professional N
Links supporting claims in the question(s) above - just two, due to lack of StackOverflow-"reputation" :(
1) Autocompletion in IPython console in PyCharm not working as it should
JetBrains (creators of PyCharm) knows about this since, at least, two years (please Google it under "PyCharm Console tab completion" or similar, I'm allowed to add just a limited number of links here), and seems to have started working on it, but never finished it.
The discussion states " this is only the initial step to getting full IPython tab completions": https://youtrack.jetbrains.com/issue/PY-9345, but the issue is closed since October 2016.
On StackOverflow there are three questions with similar wording, but not one substantial answer (no, using Ctrl+Space instead of Tab does not solve anything). Again, I can't add more links here.
_2) PyCharm not using ipython_config.py to configure IPython Console:_
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206603035-Which-ipython-config-py-is-used-to-configure-IPython-for-Python-Console-
See the comment by JetBrains at the end of the page.

Elpy to allow pyenv to work on a project basis

I've used Emacs for all my coding projects so far. Soon I will start some python projects for the first time and would love to stick to Emacs for these as well.
I was looking into elpy which seems to provide already alot of desired functionality. The part I was not able to figure out completely is the following. I like to define virtual environments and python version to be used on a project basis. Let's say I start a project A, then I would use pyenv-virtualenv or pyenv-virtualenvwrapper to set it up
pyenv virtualenv 3.4.2 my-virtual-env-3.4.2
by doing this I've linked the python version 3.4.2 to that specific virtualenv / project. I have two questions regarding this in combination with elpy.
Question: This is a rather basic one. All the above can be achieved via the terminal. What is the advantage to emacs to support this? The workflow for me would be: Create project with associated virtualenv and python version. Activate virtualenv and start coding in emacs. If I need to install a package I will run pip in the terminal to ensure virtualenv is captured properly. There must be a reason why it's beneficial to support this in emacs. With my lack of knowledge I just don't see it :)
As pointed out there is for sure a good reason why we want emacs / elpy to support this. My second question would then be
**Question: How can I achieve this in emacs? Lokks like this blog has a solution. I was wondeirng if someone already tried this setup if it is a neat solution with makes sense conceptually. **
Well I strongly guess the goal is to use more features than just syntax highlighting: flycheck/flake8/linting, refactoring, elpy's test runner to use the right python version, install a pip package directly from emacs, stuff like this. You can carry on doing this in the terminal, but once you want an emacs feature, you'll need to set it up.
IĀ found two modes to do that (see wikemacs python page and doubled-checked on melpa): pyenv-mode (in melpa) and pyenv-mode-auto (change the version when there is a .python-version file).

pylab backend from cmd prompt?

I've run into an issue...
First, I've been trying (with little success yet) of 'packaging' a Canopy python file into an .exe. I'm trying to make a 'simple' way to run our program(s) for our client.
With those issues, I thought I'd make a .cmd file with 'python myprog.py' in it. Well, it fires up my code without having the Canopy environment there to confuse my end-users, BUT, it appears that the PyLab backend isn't Qt4, as the screen appears quite a bit different, and the actual program doesn't quite run the same :(
Is there some way to tell Canopy that when I start a program using 'python xxx.py' that it should be using the Qt4 package? I've looked at the Preferences for Canopy, and both the Notebook tab and the Python tab have the PyLab backend set to Interactive (Qt4)? If I can find that and get my panels to look the same as in the Canopy environment, I'll see if the rest of the program straightens out too.
Steve, if you wish you can hard-code this into your program, but as a quick solution, precede your python call with:
set ETS_TOOLKIT=qt4

IPython notebook kernel dies on import

I am running IPython Notebook on Enthought's Canopy 64 bit distribution, Ubuntu 14.04.
I've tried install libtiff, but when I import it in IPython Notebook, the kernel always dies at the import statement. What could possibly be causing this? Canopy is my default Python distribution, my paths all seem like they're set up appropriately, although I'm convinced that something in my Python setup is borked.
Any advice is appreciated.
EDIT: I'll be more specific. Output of sys.path:
['',
'/home/joe/Enthought/Canopy_64bit/User/src/svn',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python27.zip',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/plat-linux2',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-tk',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-old',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-dynload',
'/home/joe/Enthought/Canopy_64bit/User/lib/python2.7/site-packages',
'/home/joe/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/PIL',
'/home/joe/opencv-2.4.9',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/site-packages',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/site-packages/IPython/extensions']
As for how to install Python packages, I assume I go to ~/Enthought/Canopy_64bit/User/lib/python2.7/site-packages and run pip, setup.py, or a shell script, per the specific package's instructions. Is that correct? The article that I linked has the following line: "To install a package which is not available in the Canopy / EPD repository, follow standard Python installation procedures from the OS command line.", which seems to imply that I install per package instructions.
In .bashrc, I have the following:
VIRTUAL_ENV_DISABLE_PROMPT=1 source /home/joe/Enthought/Canopy_64bit/User/bin/activate
export PYTHONHOME=/home/joe/Enthought/Canopy_64bit/User/bin
export PATH=/home/joe/Enthought/Canopy_64bit/User/bin
export PYTHONPATH=/home/joe/Enthought/Canopy_64bit/User/bin
From what I understand of the linked articles, this means I'm setting Canopy User as my default Python distribution. I'm sure I'm doing something a bit over my head here, but I can't understand what else I need to do to fix this issue.
Worse yet, now I'm getting an "ImportError: No module named site" with these .bashrc settings, when trying to start IPython notebook or python from the command line. I can run only from the Canopy GUI.
Closing this. I made it harder than necessary.
It turns out, the PYTHONHOME and PYTHONPATH .bashrc variables were causing some conflicts. Commenting them out seems to have resolved the issue.
Installing outside packages does, indeed, happen from the home (~) directory.