I have a project created in Pycharm with anaconda3 (python3) as root, and it doesnt recognize certain packages (for example in this case Seaborn package). When I try to install from terminal it says, Seaborn is already installed in anaconda2 (python2.7).
How can I manage two different versions of anaconda, because I still have to work with some legacy (python2.7) codes.
My project interpreter is already set to 3.5, whereas the terminal doesn't change accordingly.
Your situation is an ideal case for the usage of virtual environments in python.
Virtualenvs allow you to maintain versions of python without all of the dependency linking etc that it looks like you are getting into.
With Anaconda, this process is even easier as you can use the anaconda's built in manager to create a separate python 2 environment with something like the below.
conda create --name <yourenvname> python=2.7 anaconda
which will install a full blown anaconda environment in 2.7. Doing so will allow you to switch between your python 2 and python 3 without having these managment issues.
For more information see here in Anaconda on using 2or3
Related
I hope I'm clear in my question, if not please tell me.
I am using OpenImageIO's python bindings (pybind11) for some scripts that will run on hundreds of computers. Unfortunately it took me a lot of time to install OpenImageIO and make it work with my Python2 installation. I'd like to know if there's a way to create a file/folder that I could send to other computers so they can install the Python module simply with "pip install file/folder".
Thanks ofr your help
Are you running the scripts on a compute cluster with a shared filesystem? If so, then there's no need to create separate installations of python for each machine. The simplest solution is to create ONE python environment in a location that is accessible by all of your machines. An easy way to create a Python environment in a non-system location is to use Miniconda. Install it to a shared (network) location, and create an environment for all of your machines to use.
If your machines do NOT have a shared file system, then you'll need to somehow reproduce the environment on all of them independently. In this case, there's no simple way to do that with pip.**
But if you can use conda instead, then there's a very straightforward solution. First, install everything you need into a single conda environment. Then you have a choice: You can export the list of conda packages, or simply copy the entire conda environment directory to the other machines.
OpenImageIO is available from the conda-forge channel, a community-developed repository of conda packages. The name of the package is py-openimageio. They have stopped updating the python-2.7 version, but the old versions are still available.
Here's how to do it.
Install Miniconda-2.7
Create a new environment with python 2.7, OpenImageIO, and any other packages you need:
conda create -n jao-stuff -c conda-forge py-openimageio python=2.7
conda activate jao-stuff
python -c "import OpenImageIO; print('It works!')"
Do ONE of the following:
a. Export the list of packages in your environment:
conda env export -n jao-stuff -f jao-stuff-packages.yaml
Then, on the other machines, install Miniconda, then create the environments using the package list from the previous step:
conda create -n jao-stuff --file jao-stuff-packages.yaml
OR
b. Just copy all of the files in the environment to the other machines, and run them directly. Conda environments are self-contained (except for a few low-level system libraries), so you can usually just copy the whole thing to another machine and run it without any further install step.
tar czf jao-stuff.tar.gz $(conda info --prefix)/envs/jao-stuff
On the other machine, unpack the tarball anywhere and just run the python executable it contains:
tar xzf jao-stuff.tar.gz
jao-stuff/bin/python -c "import OpenImageIO; print('It works!')"
**That's because OpenImageIO is a C++ project, with several C++ dependencies, and they don't provide binaries in the wheel format. I don't blame them -- pip is not well suited to this use-case, even with wheels. Conda, on the other hand, was designed for exactly this use-case, and works perfectly for it.
PyCharm seems to ignore the configured virtualenv,
and use the base interpreter instead.
In my project at /Users/janos/dev/git/github/bashoneliners I have a virtualenv subdirectory, strictly with my project's dependencies installed in it:
$ . virtualenv/bin/activate
(virtualenv)janos at kronos in ~/dev/git/github/bashoneliners on master
$ pip -V
pip 1.5.6 from /Users/janos/dev/git/github/bashoneliners/virtualenv/lib/python3.4/site-packages (python 3.4)
(virtualenv)janos at kronos in ~/dev/git/github/bashoneliners on master
$ pip freeze
Django==1.9
Markdown==2.6.5
PyJWT==1.4.0
defusedxml==0.4.1
oauthlib==1.0.3
pep8==1.6.2
pyflakes==1.0.0
python-social-auth==0.2.13
python3-openid==3.0.9
requests==2.9.1
requests-oauthlib==0.6.0
six==1.10.0
tweepy==3.5.0
But if I add this virtualenv as Project Interpreter in PyCharm,
it shows completely different packages:
These packages are the same as in my system's base interpreter /opt/local/bin/python. This drives me nuts, I really need to use the packages from the virtualenv, not from my system.
This is with PyCharm Community Edition 5.0.3.
I didn't have this problem before with older versions of PyCharm.
I tried creating a completely new virtualenv,
both on the command line and using PyCharm,
and invalidating caches and restarting, but nothing seems to work.
PyCharm always shows the same list of packages,
and the packages of the virtualenv.
Even if I create an empty virtualenv within PyCharm,
it doesn't start empty, but filled with the same list of packages.
My project works perfectly when I run things on the command line,
such as running Django management commands, unit tests, everything.
I only have problems in PyCharm.
If I try to install packages, for example Django,
using PyCharm,
I get this error:
Of course permission denied on /opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages, that's the system interpreter.
It should be trying to install the package there,
but in /Users/janos/dev/git/github/bashoneliners/virtualenv.
Clearly it's not using pip from the virtualenv, but from the system.
I need to make to use the one from the virtualenv.
This is logged as a bug in the issue tracking system of JetBrains,
so hopefully it will get sorted out soon.
https://youtrack.jetbrains.com/issue/PY-18074
A possible workaround is to fall back to a previous version of PyCharm:
https://confluence.jetbrains.com/display/PYH/Previous+PyCharm+Releases
As of 2016 Jan 6, virtualenv works fine for me in PyCharm 4.5.4.
Some of the virtualenv previously registered using PyCharm 5.0.3 appear invalid, but that's fine. I actually deleted all registered interpreters and re-added only the virtualenv I needed.
An odd thing with this older version is that sometimes PyCharm shows the incorrect Python version (2.7 instead of 3.5), but it shows the correct list of modules as per the virtualenv, and the editor doesn't show build errors, so the Python version mixup doesn't seem to cause problems (just a bit scary).
I am trying to install django-dash to run one of the dashboard examples and see what it's like.
I am on Windows running Python 2.7 and Django 1.6.5. I know the usual approach is to download pip then install the package using pip. However, I am on a work computer with no administrative rights so I can't access my Internet Option Settings to find my proxy URL to follow the instructions below:
Proxy problems
If you work in an office, you might be behind a HTTP proxy. If so, set the environment variables http_proxy and https_proxy. Most Python applications (and other free software) respect these. Example syntax:
http://proxy_url:port
http://username:password#proxy_url:port
I had the same issue when trying to install Django but was able to get it to work by moving the django directory under Python27/Lib/site-packages. Is there something similar I can do with django-dash?
I also tried downloading the sources and running python setup.py install. I received the following error:
File "setup.py", line 3, in <module> from setuptools import setup, find_packages ImportError: No module named setuptools
Link to django-dash: http://django-dash.readthedocs.org/en/latest/
Yes, you can probably get the sources from The Python Package Index
Once you have them, uncompress the files and install them manually (this will depend on you OS).
On Linux systems:
python setup.py build
python setup.py install
Here's the full reference
EDIT : Note that when manually installing those packages, you must also install any missing dependencies, eg. setuptools in your case
I recently installed ipython, and along with it, anaconda. However, anaconda changed my sys.path directories, and some of the packages I was using before stopped working. Even after uninstalling anaconda using pip, it seems that those directories remained. How do I change them back? When I enter the python shell, I do and see the following:
Anaconda installs its own Python. When you run that Python, it uses the Anaconda Python libraries. The Anaconda installer put a line in your .profile that makes it first in the PATH, so that when you type python, it loads the Anaconda Python.
If you want to use the Python packages that you had installed into another Python with Anaconda, you will need to install them, using conda (or pip if they are not available via conda)
Anaconda is a separate python environment and as such doesn't have access to anything you installed in the base python environment. Depending on the project is usually a good idea to have separate environments using virtualenv or a similar tool. You can also do this using Anconda as described below.
Create a virtual environment for your project
conda create -n yourenvname python=x.x anaconda
Activate your virtual environment
source activate yourenvname
Install additional Python packages to a virtual environment.
conda install -n yourenvname [package]
Full description can be found at http://uoa-eresearch.github.io/eresearch-cookbook/recipe/2014/11/20/conda/
I am using Django on my Mac OS X server. Things are fine, so far. I have been using python 2.6.1 and all works well. I upgraded Python to version 2.7.3. Invoking python in the terminal brings up version 2.7.3, as expected. Checking Django using the {% debug %) reveals that Django is still using the original python 2.6.1 interpreter.
On this system, /usr/local/bin contains a symlink to ../../../Library/Frameworks/Python.framework/Versions/2.7/bin/python
In /usr/bin I find the python interpreter, and from that directory, invoking ./python gets python 2.6.1 running.
My $PATH is
/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/mysql/bin:/usr/local/bin
which I believe must have been altered on the python 2.7.3 install.
What is considered the optimal way to get the command line and Django using the same Python? I am considering either moving the framework version to /usr/bin and sitting a symlink in the framework to the moved new version. On the system is also a /Library/Python directory, that contains the site-packages for versions 2.3, 2.5, and 2.6. In /Library/Python/2.6/site-packages are the major goodies django, mercurial, and south.
Where are people putting things, nowadays? I mean, I know I could move things around, but I would like to anticipate where the Django project is going so future upgrades can go smoothly.
Install it against the updated Python.
Consider putting your app within a virtualenv container and specifying the version of Python when you create it - as per: Use different Python version with virtualenv