If Anaconda Python is installed and is the default Python (according to PATH),
then `install.sh` will fail, with a weird error message::
New python executable in /home/***/gc3pie/bin/python
ERROR: The executable /home/***/gc3pie/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/usr' (should be u'/home/***/gc3pie')
ERROR: virtualenv is not compatible with this system or executable
sh: line 378: /home/***/gc3pie/bin/activate: No such file or directory
The problem can be traced back to a bug in virtualenv; specifically,
the following lines from
<https://github.com/brandon-rhodes/homedir/blob/master/bin/%2Cfix-virtualenv-for
-anaconda>
are relevant:
> So I re-ran "virtualenv", let it die with the error, and looked at the
> incomplete environment's "bin/python2.7" and found it was the tiny
> 8,106-byte Python binary that Anaconda ships. It usually links to
> their own "libpython2.7.so" [...] But running "ldd" on the
> environment's "bin/python2.7" showed it linking to the Ubuntu
> "libpython2.7.so" instead, [...]
>
> How does the Anaconda Python binary usually wind up linking to their
> own "libpython2.7.so" instead of Ubuntu's? By, it turns out, having a
> relative RPATH - that only works if their Python binary is sitting
> right next to the "lib" directory containing their libpython
Read a full debugging session for this issue in
<https://www.s3it.uzh.ch/help/issue802>
Original issue reported on code.google.com by riccardo.murri@gmail.com on 17 Feb 2015 at 11:00
Original issue reported on code.google.com by
riccardo.murri@gmail.com
on 17 Feb 2015 at 11:00