Google Groups

Re: [Anaconda Support] PYTHONHOME woes (virtualenv, uWSGI)

Travis Oliphant Mar 8, 2014 1:38 AM
Posted in group: Anaconda - Public

On Fri, Mar 7, 2014 at 3:13 PM, <> wrote:
Hi all,

First of all: miniconda saves me a lot of trouble. My ansible playbook for building a server is a lot shorter without all installing development libraries and compiling numpy, scipy, pytables, and the like. But now I'm having trouble...

Glad you are finding the tools useful. 
This is a first-warning sign, I think:

$ pip install virtualenv
$ virtualenv foo
New python executable in foo/bin/python
foo/bin/python: error while loading shared libraries: cannot open shared object file: No such file or directory
ERROR: The executable foo/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/home/hisparc' (should be u'/home/hisparc/foo')
ERROR: virtualenv is not compatible with this system or executable

I guess that conda does something arcane in how it handles relocating the python interpreter.

Theoretically virtualenv should work inside conda environments, but it's not the recommended way to go.  It's not clear to me why you would want to create a virtualenv inside a conda environment instead of just another conda environment (flat is better than nested and all that...).   

conda is not arcane at all --- it's actually very simple.  virtualenv is *far more* complicated and brittle in how it tries to manage environments --- with a few special-cases that it gets wrong in the case of conda environments. 

conda will get confused if PYTHONHOME is set.  It can also be problematic if you have LD_LIBRARY_PATH set (or the equivalent on Mac).    

what does conda info --system tell you? 

My actual problem is trying to install and use uWSGI in an actual conda environment, not a virtualenv. I did:

$  conda create -p /srv/publicdb/env python pip --yes
$  /srv/publicdb/env/bin/pip install uwsgi
$  echo "import sys; print '\n'.join(sys.path)" >
$  /srv/publicdb/env/bin/uwsgi --python
*** Starting uWSGI 2.0.2 (64bit) on [Fri Mar  7 21:07:49 2014] ***
compiled with version: 4.4.7 20120313 (Red Hat 4.4.7-4) on 07 March 2014 21:03:05
os: Linux-2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 20:37:17 CST 2013
nodename: localhost.localdomain
machine: x86_64
clock source: unix
detected number of CPU cores: 2
current working directory: /home/hisparc
detected binary path: /srv/publicdb/env/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 1024
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
Python version: 2.7.6 |Continuum Analytics, Inc.| (default, Jan 17 2014, 10:13:17)  [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x23fd960
your mercy for graceful operations on workers is 60 seconds
mapped 72760 bytes (71 KB) for 1 cores
*** Operational MODE: command ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 32451, cores: 1)

The problem is clear: python does *not* look for libraries in the conda environment. It looks for libraries in the system-wide conda environment. If I remove miniconda from my path and use the system python to create a virtualenv and install uWSGI, the sys.path is:

The problem seems to be with uwsgi.   uwsgi is hard-coding it's dependency on system libpython rather than using the one available in the environment conda is providing.   

I suspect it's something in the pip install uwsgi....   


The same (correct) behavior happens when I activate the conda environment before running uWSGI, like this:

$ source activate /srv/publicdb/env/

Why does it not correctly set the environment when I call the uWSGI binary without activating the environment? It works for virtualenvs, why not for conda environments?

Again, I believe it's because you pip installed uWSGI and it is not setting up the paths correctly when the pip install builds uWSGI --- basically the build script for uWSGI is not respecting the actual location of libpython for the environment but picking up the system or root build of python. 

The best option is to build a conda package for uwsgi.   There are several ways to do this.  The easiest is to try: 

conda skeleton pypi uWSGI     # This will make a recipe named uwsgi in your current working directory
conda build uwsgi  --no-test      # This will build the recipe but not run the tests (which break here). 

uWSGI embeds python and how it finds the libpython it needs is getting confused is my guess.   Building the conda package with conda build will fix the bad linking step that is happening by using pip install to build. 




Best regards,

Anaconda Community Support Group Brought to you by Continuum Analytics
You received this message because you are subscribed to the Google Groups "Anaconda - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at


Travis Oliphant
Continuum Analytics, Inc.