abhilekhsingh / gc3pie

Automatically exported from code.google.com/p/gc3pie
0 stars 0 forks source link

install.sh: support the "Anaconda" Python distribution #479

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Fixed in SVN r4176 -- r4180

Original comment by riccardo.murri@gmail.com on 17 Feb 2015 at 3:19