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...
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: libpython2.7.so.1.0: 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. 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)" >app.py
$ /srv/publicdb/env/bin/uwsgi --python app.py
*** 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)
.
/home/hisparc
/opt/miniconda/lib/python27.zip
/opt/miniconda/lib/python2.7
/opt/miniconda/lib/python2.7/plat-linux2
/opt/miniconda/lib/python2.7/lib-tk
/opt/miniconda/lib/python2.7/lib-old
/opt/miniconda/lib/python2.7/lib-dynload
/opt/miniconda/lib/python2.7/site-packages
/opt/miniconda/lib/python2.7/site-packages/setuptools-2.2-py2.7.egg
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:
.
/home/hisparc
/srv/publicdb/env/lib/python27.zip
/srv/publicdb/env/lib/python2.7
/srv/publicdb/env/lib/python2.7/plat-linux2
/srv/publicdb/env/lib/python2.7/lib-tk
/srv/publicdb/env/lib/python2.7/lib-old
/srv/publicdb/env/lib/python2.7/lib-dynload
/srv/publicdb/env/lib/python2.7/site-packages
/srv/publicdb/env/lib/python2.7/site-packages/setuptools-2.2-py2.7.egg
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?
Best regards,
David