I am running IPython (and especially a notebook server) on Scientific Linux 6.3 (thus RHEL). I tried to use python3 to run setup and use ipython and also the ipython3 command. However this fails all the time. Before I go into detail with error messages and such - I read somewhere that IPython3 is currently not supported for RHEL derivates (I think the post was relating to Fedora), is this true?
Cheers
Phil
I understand that this is a fairly old question. However, given that Fedora 20 (the current version) comes with IPython 0.13 which lacks some functionality of IPython 2, I decided to write down how I installed it, in hopes that someone might find it useful. My focus was on the newest version of IPython Notebook.
Edit: I was just made aware of this IPython backport repo.
All yum and pip* commands here are to be run as the root. Those disliking such approach can prepend sudo do all yum and pip* commands and run the rest of them without sudo.
Remove RPMs of IPython (to avoid collisions):
yum remove python-ipython\* python3-ipython\*
Install pip:
yum install python-pip python3-pip
Install additional Python dependencies (it did work for me without these, but I didn't test much, so something might break down without these):
yum install python-jinja2 python-markupsafe python3-jinja2 python3-markupsafe python-devel python3-devel
Install IPython for both Python 2 and Python 3:
pip install ipython[all]
pip-python3 install ipython[all]
I've read somewhere that on Ubuntu, pip-python3 is called pip3.
To run IPython Notebook for Python 2 (do this as an ordinary user, not the root):
ipython notebook
To run IPython Notebook for Python 3 (do this as an ordinary user, not the root):
ipython3 notebook
To test your installation, call iptest or iptest3 (again, as an ordinary user, not the root). These tests may fail, so you might need additional packages for them to pass. For me, PyZMQ failed. This was fixed by installing two more packages:
yum install python-zmq-tests python3-zmq-tests
Many thanks to IPython-dev mailing list members Zoltán Vörös, for pointing me in the right direction, and Roberto Colistete Jr., for additional Python dependencies.
Related
EDIT:
In addition to the behaviour outlined below, the Python3.10 based environment seems to be ignoring packages installed with the pip -e option (development mode).
Specifically, a package installed in development mode is not listed in pip freeze (which, it does in the Python3.9 based virtual environment) and a simple import <package_name> fails. If the package is installed normally (i.e. not in development mode) everything works as expected.
I am using virtualenv to create a virtual environment based around Python 3.10. While virtualenv finishes without errors and does seem to activate, it still fails to pick up its own Python unless the PYTHONPATH environment variable has been set manually.
I am not sure if the situation I am faced with is due to Ubuntu's way of incorporating Python or the way virtualenv is setting up the environment so that it picks up a local interpreter. Here is what I have gathered this far:
My base system is an Ubuntu 21.04. It has its own Python 3 (Python3.9.5) installation which I have not touched at all except installing the python3-virtualenv package using apt.
With Python 3.10, I installed the python3.10-dev package and proceeded to create a virtual environment in the usual way:
> virtualenv -p python3.10 the_env/
> source the_env/bin/activate
Although this looks OK so far, this environment does not have any information about its own site-packages directory. Not even the one that virtualenv is supposed to be creating which includes pip. In this installation, if you try to > pip --version you simply get an error that
the pip package does not exist (the pip "executable" location is picked up correctly, but because the interpreter does not know anything about its site-packages it fails to start pip properly).
Long story short, I created two environments, one based on Python3.9 (which works perfectly) and one based on Python3.10 (which does not work) and did a very simple test in each environment:
> python -m site
On the Python3.9 environment, sys.path includes a path that leads all the way to this particular environment's site-packages
On the Python3.10 environment, sys.path does not include that particular path but still includes the typical paths you expect to find (e.g. those pointing to the interpreter itself and the top environment directory but not the specific path that points to the site-packages location.
Following this, I defined a PYTHONPATH manually, before activating the environment which points exactly to the site-packages for that particular environment and everything worked as expected.
I suspect that this might be something to do with the fact that my system's Python is 3.9 which means that the USER_SITE variable is valid while in the case of Python3.10, it is not (because, I do not have a use for it, this is just a virtual environment I am creating). So, I suspect that this might be throwing off the way the site module determines where things are.
As I am not sure, I would like to ask the following:
Could this be something to do with the way Ubuntu handles the Python installation that might just be creating this small problem with virtual environments?
Could the problem be with virtualenv that does not explicitly specify a PYTHONPATH?
Could this behaviour be something of a corner case of the site module?
What worked for me is an installation from source. After unpacking the source code, as a summary:
$ ./configure --enable-optimizations --with-ensurepip=install --prefix=/path/to/install/to/
$ make -j
$ make test
$ make install
$ /path/to/install/to/bin/python3.10 -m venv /path/to/test
$ source /path/to/test/bin/activate
$ pip list
Package Version
---------- -------
pip 21.2.4
setuptools 58.1.0
WARNING: You are using pip version 21.2.4; however, version 21.3.1 is available.
You should consider upgrading via the '/path/to/test/bin/python3.10 -m pip install --upgrade pip' command.
$ python -m pip install --upgrade pip
[...]
$ pip list
Package Version
---------- -------
pip 21.3.1
setuptools 58.1.0
Edit
As mentioned below, I believe the reason why the procedure above just works is simply that when building and installing Python from source, the installation simply will be correct, which I suspect the 3.10 installation in Ubuntu 21.04 is not.
I made my Python installation from source somewhere under my home directory, in order to not risk messing things up, and I also did not permanently modify the PATH.
Setting the path to $PATH:/path/to/install/to/bin should be fine however, either permanently, or just when running mkvirtualenv.
Doing that, my new installation even seems to integrate seamlessly with my system's virtualenvwrapper.
I don't really need to be on the Python leading edge myself, but if I did, I would definitely make myself independent of Ubuntu's latest development by using the procedure described above.
By the way, if I update pip directly in the Python installation built from source, I will no longer get the message about the older pip (see above) when I install new virtual environments.
Edit 2
Bug reported to Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/python3.10/+bug/1955742
Edit 3
Also, since Ubuntu 21.04 has end of life in a month or so, upgrading to 21.10 could really make sense. I have just tried that, and it seems that Python 3.10 virtual environments work just fine in that release.
With the advent of Ubuntu 22.04 (which caused a few minor issues with some specific python virtualenv setups I had) and having already spent some time figureing this out, I ended up switching to using pyenv.
Pyenv made it very easy to install any python version and any number of virtual environments within it which can be further customised in complete isolation.
The only thing to be careful of is installing all necessary python prerequisites before installing a specific version to avoid missing functionality from some packages (e.g. not including the lzma library will generate an ominous warning from pandas ("your python installation is incomplete..."). This can be ignored if you are not using that functionality or otherwise, easily fixed.
I think that this is a better option overall if you have to manage different versions and specific configurations for python, even across distros.
This solution is very close to the one suggested before ("install from source") so I will be accepting that one and leave my contribution as additional information about this problem.
I tried to install a certain python module that required python 3.6 minimum to work properly so I checked my version using python --version which gave me the output of Python 2.7.17 and then used python3 --version giving me Python 3.6.9. Now, I know for a fact that i have Python 3.8 installed because I ran apt install python3.8 just before checking the version.
If someone wants to know what my system is running; I am currently running Elementary OS 5.1.7 Hera.
EDIT:
(IDK what term to use, I want to say I am done going through answers, and I liked none.)
After a while of whacking my brain, I decided not to uninstall the 3.6 version as It may have version specific modules which if removed may cause other installed programs to break.
Since I just use Linux for my college-work, It wont matter if more than one versions are installed anyway.
Sorry for any mistakes I may have made, I was never good at this kind of things.
Use conda to install and manage different versions of Python (or lots of other software, for that matter). Install different Python versions in separate conda environments. For example:
Find what python versions are available:
conda search python
Output (as of the time of writing, in the future I expect that the latest Python versions will be higher):
Loading channels: done
# Name Version Build Channel
python 1.0.1 0 conda-forge
python 1.2 0 conda-forge
...
python 3.9.0 h88f2d9e_1 pkgs/main
python 3.9.0 ha017127_4_cpython conda-forge
Install the Python versions you need in separate environments. Here, install Python 3.9.0 in environment named python39:
conda create --name python39 python=3.9.0
Switching environments is easy:
conda activate python39
# python is now 3.9.0
conda deactivate
# back to the default python
or (deprecated now):
source activate python39
source deactivate
SEE ALSO:
conda docs: Managing environments
This question is more appropriate for Unix & Linux.
Python installations (more generally, versioned installations of software) co-exist on linux using version numbers. You can likely run Python 3.8 using the python3.8 command (or else, locate where you installed it and run from there / add the location to the PATH environment variable to run directly).
Likewise, for each python version you can install its own package manager (e.g. install pip3.8 by python3.8 -m pip install pip) and use it to install packages for that python version. (As different projects require different sets of packages, the general practice is to create a "virtual environment", i.e. a separate copy of the needed version of python, pip and their package installation folders for each project, and install the required packages there - for more information see e.g. this excellent answer).
Regarding the command python3 (usually /usr/bin/python3) is just a symbolic link, you can replace it with the version you like (as long as it remains compatible with what the system expects - i.e. python3 of version no less than your built-in python3/python3-minimal, otherwise you will probably break something), e.g. assuming which python3 gives you /usr/bin/python3, you can
sudo rm /usr/bin/python3 #remove existing link
sudo ln /usr/bin/python3.8 /usr/bin/python3 # create a new link to the version of your choice
(although a better alternative could be instead aliasing it alias python3='/usr/bin/python3.8' and adding this to ~/.bashrc).
Whatever you do, do not uninstall python3-minimal as it is - at least, on Ubuntu - required by the system and uninstalling or changing it will likely break the system.
There is a lot of information available to run Jupyter Notebook with Anaconda but could not find any info to run Jupyter without Anaconda.
Any pointer would be much appreciated!
Basically the process is as follows:
pip3 install --upgrade pip
pip3 install jupyter
jupyter notebook # run notebook
Run a specific notebook:
jupyter notebook notebook.ipynb
Using custom IP or port:
jupyter notebook --port 9999
No browser:
jupyter notebook --no-browser
Help:
jupyter notebook --help
Answer from the following sources:
SOURCE 1
SOURCE 2
See Gordon Ball's Jupyter PPA, the most actively maintained Jupyter PPA as of this writing with support for both Ubuntu 16.04 and 18.04 (LTS).
Installation: It's a Ball
Thanks to Gordon's intrepid efforts, installation of Jupyter under Ubuntu trivially reduces to:
sudo add-apt-repository ppa:chronitis/jupyter
sudo apt-get update
sudo apt-get install jupyter
Doing so installs the jupyter metapackage, providing:
A standard collection of Jupyter packages published by this PPA, including:
Jupyter's core and client libraries.
Jupyter's console interface.
Jupyter's web-based notebook.
Tools for working with and converting notebook (ipynb) files.
The Python3 computational kernel.
The /usr/bin/jupyter executable.
As W. Dodge's pip-based solution details, the browser-based Jupyter Notebook UI may then be launched from a terminal as follows – where '/home/my_username/my_notebooks' should be replaced with the absolute path of the top-level directory containing all of your Jupyter notebook files:
jupyter notebook --notebook-dir='/home/my_username/my_notebooks'
Why Not Acanaconda or pip?
For Debian-based Linux distributions, the optimal solution is a Debian-based personal package archive (PPA). All other answers propose Debian-agnostic solutions (e.g., Anaconda, pip), which circumvent the system-wide APT package manager and hence are non-ideal.
Installing Jupyter via this or another PPA guarantees automatic updates to both Jupyter and its constellation of dependencies. Installing Jupyter via either Anaconda or pip requires manual updates to both on an ongoing basis – a constant thorn in the side that you can probably do without.
In short, PPA >>>> Anaconda >> pip.
There are two ways to install Jupyter-Notebook in Ubuntu. One is using Anaconda, the other using pip. Please go through the below added link for details.
http://jupyter.readthedocs.io/en/latest/install.html
I'm having a ROS-node that uses Python 3.5 and I want to run it on ROS-Kinetic. This is supposed to run on Ubuntu 16.04 with Kernel 4.4.
I've read that it's complicated to match ROS-Kinetic with Python 3 because it's not officially supported...but I've also read that it is possible to do so...
There are several installation guides for specific packages and I've tried some of them but failed everytime.
What I've tried so far:
1) Installed ROS-Kinetic-desktop-full
2) pip3 install rospkg catkin_pkg
3) export PYTHONPATH = /usr/local/lib/python3.5/dist-packages
When I'm running catkin_make, the first error appearing says:
... ImportError: No module named genmsg ...
Can anyone please write an exact installation guide for making ROS-Kinetic run with Python 3.5 (without a virtual environment) or tell me what's missing in my installation?
Thanks in advance!
An alternative to Some progammer's answer, you could install the packages in global space
sudo apt-get install python3-yaml # you'll also need this
sudo pip3 install rospkg catkin_pkg
or add --user flag
pip3 install --user rospkg catkin_pkg
People used Python 3.5 + ROS-Kinetic in Ubuntu before (for example, check out cozmo_driver) and it should work according to REP3.
You are not exporting the right folder to PYTHONPATH. Try
export PYTHONPATH=/opt/ros/kinetic/lib/python2.7/dist-packages/
It bugs me theese simple things:
I notice that my installed lxml can't be found from my python3.1 shell.
There is no problem in python2.6 shell
So my question now is - how can I install lxml to python3.1? sudo pip install lxml just tells me that lxml is already installed.
I know I could properbly use virtualenv to do this - but quite honestely I am just trying to learn python in the most simple manner posible. I therefore don't think I need "package lockdown" the way I (mis)understands virtualenv provides. Anything that can keep the confusion at bay and let me focus on the programming :-)
I could of course just uninstall python2.6 but I guess all hell would break loose on my debian box then.
Thanks in advance
Each version of Python is independent of the others. This goes for everything including pip commands. You need to install pip once per each version, and you then get one pip command per version.
For a longer explanation, see my blog post on the topic.