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: 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.
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:
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.