IPython kernel restarts after installing new module - python

I was using "ipython" with "qtconsole" (it works perfectly) after I install some new third-party module and the "notebook" it stops working and the kernel restarts continually.
the Error is here:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.7/dist-packages/IPython/kernel/__init__.py", line 10, in <module>
raise ImportError(__doc__)
ImportError: IPython.kernel has been replaced by IPython.parallel.
The previous version of IPython's parallel library was located at this
location (IPython.kernel). It has been moved to the IPython.parallel
subpackage and has been refactored to use zeromq/pyzmq instead of twisted.
Please see INSERT URL for further details.
[IPythonQtConsoleApp] WARNING | kernel restarted
how can I fix this issue?
the Error says "Please see INSERT URL for further details." where can I find this "INSERT URL" ???
thank you.

You have multiple versions of IPython installed, and it's getting confused. The version in /usr/lib is installed with apt, and old (pre-1.0).
The shortest workaround, if available to you, would be to apt-get remove ipython, leaving only one IPython on your system.
The most likely cause of this issue, since you say it was caused by installing another package, is easy_install. It is possible for easy_install to incorrectly add dist-packages to easy-install.pth when you already have a package installed with apt. To check this, look at the files (if they exist):
~/.local/lib/python2.7/site-packages/easy-install.pth
/usr/local/lib/python2.7/dist-packages/easy-install.pth
If there are any entries starting with /usr/lib/python2.7/dist-packages, they should be removed.

Related

Removing preloaded python modules

I want to use the kitsu module in python. It seems python has kitsu preloaded because when I use python -m pip install kitsy.py it installs no problem. But when I try to run the basic test code they have on https://pypi.org/project/kitsu.py/ it tells me the following error.
Traceback (most recent call last):
File "c:\Users\ssolmonson\AppData\Local\Programs\Python\Github\Personal\kitsu.py", line 1, in <module>
import kitsu
File "c:\Users\ssolmonson\AppData\Local\Programs\Python\Github\Personal\kitsu.py", line 4, in <module>
client = kitsu.client()
AttributeError: partially initialized module 'kitsu' has no attribute 'client' (most likely due to a circular import)
I have looked all over on how to completely remove a preloaded module with little success.
I can see the kitsu module listed when using help('modules'). Some places said to run python -m pip uninstall kitsy.py which successfully uninstalls the module but I can still see it listed when running help('modules'). Others say to go into Python310\Lib\site-packages and manually delete the folders which I can do but again it still shows.
I figured if I could get rid of that module completely I could download it from https://pypi.org/project/kitsu.py/ and install it from the package I got from the website. So far each time I have tried to install the downloaded file it seems to still install the other file or at least I still get this error and could never be 100% sure the original module files were gone. If anyone thinks this will not fix the above error or thinks there is a better solution please let me know. I am truly grasping at straws.

Difficulty importing packages to interpreter in Pycharm [duplicate]

In trying to install packages in Pycharm for the Python 3.6 interpreter, I get
Python packaging tools not found. *Install packaging tools*
And when I tried to install it gives me this error
Traceback (most recent call last):
File "C:\Program Files\JetBrains\PyCharm Community Edition
2017.3.1\helpers\packaging_tool.py", line 2, in <module>
import traceback
ModuleNotFoundError: No module named 'traceback'
I'm using Pycharm 2017.3.1 Community Edition
From pycharm,
goto settings -> project Interpreter
Click on + button on top right corner and you will get pop-up window of Available packages. Then search for packaging python package.
Then click on Install package to install the package.
I had a similar issue. In the end I had to remove an existing venv that was in the same location, delete multiple interpreters, then set up a new one.
For what it's worth..
I had a similar problem. Nothing answered here worked for me.
The problem started with Pycharm upgrade. The solution was to uninstall Pycharm, and obliterate what's in the Configuration directory (https://www.jetbrains.com/help/pycharm/directories-used-by-the-ide-to-store-settings-caches-plugins-and-logs.html#config-directory) along with alll jetbrains directories.
Reinstalled Phycharm 2022.1.1. Viola. Alas I have to reinstall all plugins I used in the old installation.
As far as I can tell, the problem - in my case at least - was the upgrade process.
The accepted answer wouldn't directly work if you have already created a Virtual environment.
That virtual environment would not be usable. So, go ahead and delete it.
Then, go and install the packaging module in the base python version, as shown in the accepted answer and then create a new virtual environment.
That new virtual environment can now be used.

How to setup libusb for a conda Python environment in Mac

So I'm trying to use pyusb in a conda environment but it fails with error below:
>>> import usb.core
>>> usb.core.find()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/foo/Developer/anaconda3/envs/delme/lib/python3.6/site-packages/usb/core.py", line 1263, in find
raise NoBackendError('No backend available')
I'm assuming this happens because it can't find libusb. I have tried installing libusb and libusb1 inside the conda environment via pip and also system-wide (libusb and libusb-compat) via brew but none of these have helped.
I figured out what's happening so I might as well answer my own question – someone else might find it useful.
For reasons that I don't remember anymore I had added some paths to DYLD_FALLBACK_LIBRARY_PATH when I was trying to compile something. According to dyld's manual the default value for DYLD_FALLBACK_LIBRARY_PATH is $(HOME)/lib:/usr/local/lib:/lib:/usr/lib which covers where libusb is but looks like by extending DYLD_FALLBACK_LIBRARY_PATH it's lost those default values.
So if you have similar issues you might want to take a look at these variables.

Python failing to install module "spacepy"

I'm currently trying to install the Python package spacepy due to its ability to read CDF files, along with a few other useful functions. However, any time I try to install this module I receive a myriad of errors - whether I try to install it via Anaconda, command prompt, or by downloading the package manually and running setup.py from the package directory. Currently, I've spent hours trying to chase down these errors, but as I'm not a programmer it's been slow going.
I've managed to "install" it, however the module throws an error when trying to load it:
Traceback (most recent call last):
File "<ipython-input-1-4bcf91e29885>", line 1, in <module>
import spacepy
File "C:\Anaconda\lib\site-packages\spacepy\__init__.py", line 329, in <module>
_read_config(rcfile)
File "C:\Anaconda\lib\site-packages\spacepy\__init__.py", line 297, in _read_config
_write_defaults(rcfile, defaults)
File "C:\Anaconda\lib\site-packages\spacepy\__init__.py", line 236, in _write_defaults
key=k, value=defaults[k], ver=__version__))
IOError: [Errno 0] Error
...and so I don't believe it's been installed properly, and one or more of the errors from the initial build is causing issues.
This package has a number of dependencies, most being other Python modules. The only one that the installer would be unable to do itself would be the Fortran compiler (for which I have installed myself using MinGW), however this shouldn't prevent the package from installing.
Here is the complete log of errors that I recieve when trying to force-reinstall it via the command prompt:
python -m pip install --upgrade --force-reinstall spacepy
So it turns out that, among a few smaller errors with the dependencies here and there (that could be fixed just by following the errors thrown), the major issue was the version of numpy. Spacepy was designed for numpy v1.6, and doesn't seem to be backwards compatible with future versions of numpy (like the current v1.12).
Rolling back my version of numpy, as well as moving over to a linux virtual environment (which allowed complete control of modules and dependencies) eventually got spacepy on my system. Now I've just got to become more familiar with linux!

Using MacPorts to install modules via a certain path

I realize this is a very newbie question, but previous threads haven't been encouraging (see details below).
I've been using anaconda for most of my work via the IPython Notebook, python 2.7
However, there is a module which I could only properly download with MacPorts. Hence the current problem: when I try to use the Python command line in Terminal or use IPython notebooks, I will enter
import py-module
and I get
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named py-module
So, obviously the $PATH is wrong. All my previous modules have been saved with conda to /anaconda/bin, but using sudo port install py-module is going to save in a different file, /opt/local.
Is it possible to set the path such that MacPorts will install a module into anaconda/bin
such that I can import this module on ipython notebook via conda?
Previous threads have suggested simply choosing one or the other, i.e. removing anaconda entirely
rm -r ~/anaconda
and then just reinstalling all packages via MacPort. But I would prefer not to do this. Can't I re-direct the path such that
sudo port install py-module
installs the module into `/anaconda/bin/' ?
For previous takes, see
Getting PyGame to import in Python interpreter after MacPorts install
While you could adjust your PYTHONPATH environment variable or modify the path using sys.path.insert, you should not try to mix a Python module built for MacPorts' Python with Anaconda. This may work just fine if the module is python-only, but as soon as the module contains compiled code it is not certain that the two installations are binary-compatible. In the best case, loading the module will fail if it isn't compatible, in the worst case, it will randomly crash.
So, yes, you should decide for one Python and just use that.

Categories

Resources