TRAMP anaconda server issues after recent update

[r-zip]

First of all, thanks a ton for this package. Best autocomplete out there for Python, IMO, and I really appreciate the remote completion features.

After installing the latest MELPA version of anaconda-mode, I have had issues getting any features to work when accessing files over TRAMP. In the *anaconda-mode* buffer, I found the following:

/path/to/project/venv/lib/python3.6/site-packages/IPython/core/interactiveshell.py:925: UserWarning: Attempting to work in a virtualenv. If you encounter problems, please install IPython inside the virtualenv.
  warn("Attempting to work in a virtualenv. If you encounter problems, please "

InvalidPythonEnvironmentTraceback (most recent call last)
<ipython-input-1-fe2fa803d967> in <module>
     82 
     83 if virtual_environment:
---> 84     virtual_environment = jedi.create_environment(virtual_environment, safe=False)
     85 else:
     86     virtual_environment = None

/path/to/project/venv/lib/python3.6/site-packages/jedi/api/environment.py in create_environment(path, safe)
    340         _assert_safe(path, safe)
    341         return Environment(path)
--> 342     return Environment(_get_executable_path(path, safe=safe))
    343 
    344 

/path/to/project/venv/lib/python3.6/site-packages/jedi/api/environment.py in _get_executable_path(path, safe)
    353         python = os.path.join(path, 'bin', 'python')
    354     if not os.path.exists(python):
--> 355         raise InvalidPythonEnvironment("%s seems to be missing." % python)
    356 
    357     _assert_safe(python, safe)

however, I double-checked that my python-shell-virtualenv-root and python-shell-virtualenv-path variables were correct, and that ipython and python were indeed executables in the venv/bin folder. I had no issues before updating (but I do not know my previous version).

I even tried removing anaconda-mode directories on both computers and letting it reinstall, disabling my config, etc. No matter what I do, I have this issue.

Could it have to do with my remote host shell .profile? I'm kind of at a loss where to look next.

[proofit404]

Hi, sorry about that.

I just reverted https://github.com/proofit404/anaconda-mode/pull/357

Let me know if this fixes the issue.

[falloutphil]

Hi @r-zip

If reverting the patch works, please can you provide a minimum set of steps to reproduce the issue?

I suspect the issue is the interplay between Tramp and virtualenv - in which case starting with creating the simplest virtual environment and then simplest way to break it - could you walk me though how to reproduce it.

I don't usually use virtualenv, so please make sure the instructions make no assumptions :-)

If you want to switch between the previous working and new broken version - the new broken version is available here: https://github.com/falloutphil/anaconda-mode/blob/master/anaconda-mode.el

Once I can reproduce it I'll (hopefully) fix it.

[r-zip]

@falloutphil I'll do that once I have some time this evening. For now, I tried it using anaconda-mode-20190616.1019 from MELPA, and I get the same issue.

It looks like maybe the path is not being translated from TRAMP syntax correctly: the following error message appears in *anaconda-mode*:

/path/to/project/venv/lib/python3.6/site-packages/IPython/core/interactiveshell.py:925: UserWarning: Attempting to work in a virtualenv. If you encounter problems, please install IPython inside the virtualenv.
  warn("Attempting to work in a virtualenv. If you encounter problems, please "

InvalidPythonEnvironmentTraceback (most recent call last)
<ipython-input-1-fe2fa803d967> in <module>
     82 
     83 if virtual_environment:
---> 84     virtual_environment = jedi.create_environment(virtual_environment, safe=False)
     85 else:
     86     virtual_environment = None

/path/to/project/venv/lib/python3.6/site-packages/jedi/api/environment.py in create_environment(path, safe)
    340         _assert_safe(path, safe)
    341         return Environment(path)
--> 342     return Environment(_get_executable_path(path, safe=safe))
    343 
    344 

/path/to/project/venv/lib/python3.6/site-packages/jedi/api/environment.py in _get_executable_path(path, safe)
    353         python = os.path.join(path, 'bin', 'python')
    354     if not os.path.exists(python):
--> 355         raise InvalidPythonEnvironment("%s seems to be missing." % python)
    356 
    357     _assert_safe(python, safe)

InvalidPythonEnvironment: /ssh:username@ip_address:/path/to/project/venv/bin/python seems to be missing.

It's strange that the /ssh:username@ip_address: portion of that path appears in the Python traceback. I'd expect that all paths that Emacs sends to the Python JSON RPC server would have the TRAMP information removed. Is that helpful?

[falloutphil]

@r-zip indeed, I doubt Python should be trying to join() a Tramp path. I'll see if I can spot what I've changed that is being used specifically for virtual envs.

Can you confirm the path is correct on the server without the tramp prefix, i.e this exists: /path/to/project/venv/bin/python

[r-zip]

@falloutphil Yes, it does. I've checked multiple times from both bash and Python.

[falloutphil]

For now, I tried it using anaconda-mode-20190616.1019 from MELPA, and I get the same issue.

@r-zip @proofit404 I've double checked the source code here: https://melpa.org/packages/anaconda-mode-20190616.1019.el

This version doesn't contain #357 so whatever the issue is, it isn't caused by this PR, given @r-zip is seeing the issue in this MELPA version.

This makes sense to me - having reviewed the error message given by @r-zip this looks to me to be occurring after the RPC session has been started, and on the remote server. The changes in #357 solely deals with the creation of the tunnel for the RPC calls to pass through. If #357 was causing a failure I'd expect it to fail to connect to the RPC server at all, and not fail due to the parameters provided within the subsequent RPC calls.

At a total guess I suspect that in anaconda-mode-jsonrpc-request-data the expression (pythonic-python-readable-file-name (buffer-file-name)) is taking in the Tramp formatted filename for the buffer in question, and not correctly identifying the path as being of Tramp format.

You can see this here: https://github.com/proofit404/pythonic/blob/master/pythonic.el#L129

I note this function uses tramp-tramp-file-p directly, and at a total guess perhaps needs its use updated as per: https://github.com/proofit404/pythonic/commit/6a5a2a365e4ea6fc5adfa96359418c437aa351c8

I'm going out on a limb here - so my guess work as to what the problem might be, may not be right, but I'm fairly certain the problem isn't #357 - unless you disagree?

If I am right about the issue the MELPA packages for both anaconda-mode and the underlying pythonic package will need to be investigated.

[falloutphil]

If we're closing this can we reinstate #357 - nobody has ever provided evidence this has caused a problem, and it adds useful functionality and fixes issues with TRAMP usage?

[CeleritasCelery]

That sounds reasonable. It seems like #357 was not the cause here. Let me look into it more.

[falloutphil]

Thanks - shout if you need any further details from me on #357

[CeleritasCelery]

@falloutphil I reinstated your PR. I am going to keep an open eye to see if it leads to issues.