iPython and symlink from .virtualenvs to .local/share/virtualenvs causes: WARNING: Attempting to work in a virtualenv. If you ...

[tcorbettclark]

I encountered an issue with iPython running inside a virtualenv freshly made by pew. Note that this might be an iPython problem...

The symptoms are the following warning when invoking iPython from within the virtualenv:

WARNING: Attempting to work in a virtualenv. If you encounter problems, please install IPython inside the virtualenv.

The following is my analysis of what may be wrong...

When pew creates the first virtualenv for a Linux user it creates a symlink from ~/.virtualenvs to ~/.local/share/virtualenvs: https://github.com/berdario/invewrapper/blob/master/invewrapper/invewrapper.py#L80

That means that pip installed packages will have entry scripts which use the .local/share version of python. See the first (#!) line below (which is being run from within the virtualenv):

tcorbettclark@cmed1:~$ cat $(which ipython)
#!/home/tcorbettclark/.local/share/virtualenvs/ice/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'ipython==1.1.0','console_scripts','ipython'
__requires__ = 'ipython==1.1.0'
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
    sys.exit(
        load_entry_point('ipython==1.1.0', 'console_scripts', 'ipython')()
    )

However the VIRTUAL_ENV environment variable will not use the followed symlink. See the last line of:

tcorbettclark@cmed1:~$ python
Python 2.7.3 (default, Sep 26 2013, 16:35:25) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['VIRTUAL_ENV']
'/home/tcorbettclark/.virtualenvs/ice'

The problem is that iPython uses string comparison to detect whether it is running inside a virtualenv or not: https://github.com/ipython/ipython/blob/5bf4949fbd30de6211226e4b27e8680c4b199fc9/IPython/core/interactiveshell.py#L719. These paths are not a prefix of one another because one has the expanded symlink and one does not.

My workaround was to stop pew from creating the symlink by manually creating the ~/.virtualenvs directory before creating the very first virtualenv i.e.: mkdir -p .virtualenvs.

[berdario]

Thank you for the bug report

The rationale for having such a symlink was that I strive to respect the XDG base dir spec and to have a clean home directory, but on the other hand I want to stay compatible with virtualenvwrapper

The idea would be to keep the symlink only until most pew-like tools use XDG_DATA_HOME by default, or compatibility with virtualenvwrapper wouldn't be requested anymore

Actually, it's debatable my choice of using the DATA directory for the virtualenvs given that they contain executables ("executable data"? but it's surely more appropriate than CONFIG or CACHE)

I'm sorry that this issue slipped through... I wonder if it'd be better to just get rid of the symlinks as soon as possible

[tcorbettclark]

No problem

Thanks for such a quick and considered response!

Convention vs standards... Or shim to bridge, accepting it may not be
perfect. Or just branch out to the better way... This is what much software
engineering is about! I think if it were me I would separate the concerns
by keeping compatibility with virtualenvwrapper conventions today and talk
to Doug H about bringing both in line with standards in future releases.
That way you leverage the largest user base.

I don't really understand the details but it seems like the bug here is
with ipython anyway.

Great tool by the way. Thanks!

Sent from my Nexus 4
On 4 Nov 2013 13:41, "berdario" notifications@github.com wrote:

Thank you for the bug report

The rationale for having such a symlink was that I strive to respect the
XDG base dir spec and to have a clean home directory, but on the other hand
I want to stay compatible with virtualenvwrapper

The idea would be to keep the symlink only until most pew-like tools use
XDG_DATA_HOME by default, or compatibility with virtualenvwrapper wouldn't
be requested anymore

Actually, it's debatable my choice of using the DATA directory for the
virtualenvs given that they contain executables ("executable data"? but
it's surely more appropriate than CONFIG or CACHE)

I'm sorry that this issue slipped through... I wonder if it'd be better to
just get rid of the symlinks as soon as possible

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-27685093
.