tkf / emacs-jedi

Python auto-completion for Emacs
http://tkf.github.io/emacs-jedi/latest/
666 stars 89 forks source link

pkg_resources.DistributionNotFound: jedi>=0.7.0 #184

Closed colonelpanic8 closed 8 years ago

colonelpanic8 commented 9 years ago

I've been getting this error after installing jedi a virtualenvironment using jedi:install-server

Traceback (most recent call last):
  File "/Users/imalison/.emacs.d/.python-environments/default/bin/jediepcserver", line 5, in <module>
    from pkg_resources import load_entry_point
  File "build/bdist.macosx-10.10-x86_64/egg/pkg_resources.py", line 2951, in <module>
    working_set = WorkingSet._build_master()
  File "build/bdist.macosx-10.10-x86_64/egg/pkg_resources.py", line 563, in _build_master
    return cls._build_from_requirements(__requires__)
  File "build/bdist.macosx-10.10-x86_64/egg/pkg_resources.py", line 576, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "build/bdist.macosx-10.10-x86_64/egg/pkg_resources.py", line 755, in resolve
    raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: jedi>=0.7.0

I'm using a homebrew installed python, and I suspect that this may have something to do with that. I haven't had any time to investigate, but I just wanted to post this here in case anyone else is having this issue. I've been able to work around this issue by editing ~/.emacs.d/.python-environments/default/lib/python2.7/site-packages/jediepcserver-0.0.0-py2.7.egg-info/requires.txt so that it doesn't care about the version of jedi used (i.e replace jedi>=0.7.0 with just jedi).

Here is some basic information about my system:

Version of emacs-jedi ;; Version: 0.2.0alpha2

uname -v Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64

python --version Python 2.7.9

type -a python python is /usr/local/bin/python

readlink -f $(which python)
/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/bin/python2.7

Inside of virtualenv created by jedi install: source ~/.emacs.d/.python-environments/default/bin/activate && pip freeze

Flask==0.10.1
Flask-RESTful==0.3.1
Jinja2==2.7.3
MarkupSafe==0.23
PyYAML==3.11
SQLAlchemy==0.9.8
Werkzeug==0.9.6
aniso8601==0.90
argparse==1.3.0
astroid==1.3.2
cider==1.1.5
click==3.3
coloredlogs==0.8
contextlib2==0.4.0
ddg==0.2.2
dotfiles==0.6.3
dropbox==2.2.0
epc==0.0.5
flake8==2.2.5
gevent==1.0.1
gevent-socketio==0.3.6
gevent-websocket==0.9.3
gnureadline==6.3.3
greenlet==0.4.5
invoke==0.9.0
ipython==2.3.1
itsdangerous==0.24
jedi==0.8.1-final0
jediepcserver==0.0.0
logilab-common==0.63.2
lxml==3.4.1
mccabe==0.3
mercurial==3.2.3
mock==1.0.1
numpy==1.9.1
okcupyd==0.8.15
ouimeaux==0.7.3
pep8==1.5.7
powerline-status==dev-f34ab66ea22309cf1b60bc104c76528ce29c82b3
psutil==2.1.3
py==1.4.26
pyflakes==0.8.1
pylint==1.4.0
pysignals==0.1.2
pytz==2014.10
readline==6.2.4.1
requests==2.5.0
rfc3987==1.3.4
rope==0.10.2
ropemacs==0.7
ropemode==0.2
sexpdata==0.0.3
simplejson==3.6.5
six==1.8.0
tox==1.8.1
urllib3==1.10
vcrpy==1.1.3
virtualenv==1.11.6
wrapt==1.10.2
wsgiref==0.1.2

source ~/.emacs.d/.python-environments/default/bin/activate && python --version Python 2.7.9

syohex commented 9 years ago

I cannot reproduce this issue. Could you retry after upgrading pip ?

Reference

colonelpanic8 commented 9 years ago

I had already tried that, but I did it again just to make sure and it had no effect.

muonzoo commented 9 years ago

I am having the same error - jedi mode unusable with same symptoms. Seemed to be working for me last week. Jedi claims to be 0.8.1-final0.

pip freeze:

Cheetah==2.4.4
Flask==0.10.1
GDAL==1.11.1
Glances==2.0.1
Jinja2==2.7.3
Markdown==2.3.1
MarkupSafe==0.23
Pillow==2.5.3
Pygments==2.0.1
Sphinx==1.2.3
Unidecode==0.04.14
Werkzeug==0.9.4
argparse==1.3.0
arrow==0.4.4
azure==0.8.0
backports.ssl-match-hostname==3.4.0.2
beautifulsoup4==4.3.2
bokeh==0.3-421-g692564e-dirty
brewer2mpl==1.4
certifi==14.05.14
colorama==0.2.7
docutils==0.12
epc==0.0.5
gevent==1.0
gevent-websocket==0.9.2
ggplot==0.5.0
gnureadline==6.3.3
gprof2dot==1.0
greenlet==0.4.2
ipython==2.3.1
itsdangerous==0.23
jedi==0.8.1-final0
jediepcserver==0.0.0
keyring==3.8
lxml==3.3.0
matplotlib==1.4.2
networkx==1.8.1
nose==1.3.3
numpy==1.8.1
pandas==0.15.2
patsy==0.3.0
psutil==2.1.1
pydot==1.0.28
pyfiglet==0.7.1
pygraphviz==1.2
pyparsing==2.0.2
python-dateutil==2.2
python-ntlm==1.0.1
pytz==2014.4
pyzmq==14.4.1
qrcode==5.0.1
rainbowstream==0.9.5
redis==2.9.1
requests==2.2.1
requests-ntlm==0.0.2.3
rpy2==2.4.3
scipy==0.14.0
seaborn==0.5.1
sexpdata==0.0.3
simpy==3.0.5
six==1.7.3
smartypants==1.8.3
sphinx-bootstrap-theme==0.3.6
statsmodels==0.5.0
stevedore==0.13
sympy==0.7.5
tornado==4.0
twitter==1.15.0
ujson==1.33
unicodecsv==0.9.4
virtualenv==1.11.6
virtualenv-clone==0.2.4
virtualenv-tools==1.0
virtualenvwrapper==4.2
wsgiref==0.1.2
xlrd==0.9.2
xlwt==0.7.5
yolk==0.4.3

NOTE that jedi is version 0.8.1-final0.

colonelpanic8 commented 9 years ago

@muonzoo Did you try my suggestion to modify ~/.emacs.d/.python-environments/default/lib/python2.7/site-packages/jediepcserver-0.0.0-py2.7.egg-info/requires.txt so that it doesn't care about the version of jedi used (i.e replace jedi>=0.7.0 with just jedi)

muonzoo commented 9 years ago

Yes my ~/.emacs.d/.python-environments/default/lib/python2.7/site-packages/jediepcserver-0.0.0-py2.7.egg-info/requires.txt file:

jedi
epc>=0.0.4
argparse

And this installs and appears to run. I'm now having an unrelated yasnippet issue..

anedos commented 9 years ago

I'm also having the same issue, which I think is related to a brew install --upgrade python I did last week. It's the only change that's happened in my system; I moved from python 2.7.8 to 2.7.9.

@IvanMalison fix worked like a charm, thanks.

jschaf commented 9 years ago

Same issue, @IvanMalison fix solved the problem for me.

muonzoo commented 9 years ago

I am experiencing this issue but I am still on 2.7.8 -- I did do a brew upgrade of a few packages though so it is possible that this is completely consistent with @anedos' experiences. The @IvanMalison fix also worked for me - yasnippet issue previously mentioned is (of course) 100% unrelated.

colonelpanic8 commented 9 years ago

@muonzoo @anedos @jschaf Is everyone here on yosemite?

muonzoo commented 9 years ago

Yes : $ uname -a Darwin tupolev-wired.lan 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64 System Version: OS X 10.10.1 (14B25)

jschaf commented 9 years ago

Yes, I'm on Yosemite

syohex commented 9 years ago

I cannot reproduce this issue with Mac OSX Yosemite and homebrew python 2.7.9. Would you tell us how to reproduce this issue ?

colonelpanic8 commented 9 years ago

@syohex what version of jedi is installed in the virtualenv of your jedi server?

syohex commented 9 years ago

0.8.1.

Here is output of M-x jedi:show-version-info

(:emacs-version "24.4.1" :jedi-version "0.2.0alpha2")
((:version "2.7.9 (default, Dec 30 2014, 18:28:09) \n[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)]" :name "sys" :file nil)
 (:version "0.8.1" :name "jedi" :file "/Users/syohei/.emacs.d/.python-environments/default/lib/python2.7/site-packages/jedi/__init__.pyc")
 (:version "0.0.5" :name "epc" :file "/Users/syohei/.emacs.d/.python-environments/default/lib/python2.7/site-packages/epc/__init__.pyc")
 (:version "0.0.3" :name "sexpdata" :file "/Users/syohei/.emacs.d/.python-environments/default/lib/python2.7/site-packages/sexpdata.pyc"))
colonelpanic8 commented 9 years ago

Hmm, my version info is slightly different (notice the -final0 at the end of the jedi version)

(:emacs-version "24.4.1" :jedi-version "0.2.0alpha2")
((:version "2.7.9 (default, Dec 30 2014, 18:28:09) \n[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)]" :name "sys" :file nil)
 (:version "0.8.1-final0" :name "jedi" :file "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/jedi/__init__.pyc")
 (:version "0.0.5" :name "epc" :file "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/epc/__init__.pyc")
 (:version "0.0.3" :name "sexpdata" :file "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/sexpdata.pyc"))

But I actually have another computer for which it is the same:

(:emacs-version "24.4.1" :jedi-version "0.2.0alpha2")
((:version "2.7.9 (default, Dec 30 2014, 18:28:09) \n[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)]" :name "sys" :file nil)
 (:version "0.8.1-final0" :name "jedi" :file "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/jedi/__init__.pyc")
 (:version "0.0.5" :name "epc" :file "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/epc/__init__.pyc")
 (:version "0.0.3" :name "sexpdata" :file "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/sexpdata.pyc"))

but force which I have encountered no issues.

I wonder why you are getting a slightly different version of jedi.

muonzoo commented 9 years ago

This -final0 appears to be part of the problem. I had an error message saying that the version info could not be parsed. Somehow this causes the >= 0.7.0 condition to fail. See my comment from 14d ago above.

syohex commented 9 years ago

Should we apply the fix like following ?

https://github.com/amjith/pgcli/commit/09f7ac55d02cbacb00f448020afb4483fcee1fca

diff --git a/setup.py b/setup.py
index b450558..3dbd85c 100644
--- a/setup.py
+++ b/setup.py
@@ -14,7 +14,7 @@ setup(
     name='jediepcserver',
     py_modules=['jediepcserver'],
     install_requires=[
-        "jedi>=0.7.0",
+        "jedi==0.8.1",
         "epc>=0.0.4",
         "argparse",
     ],
colonelpanic8 commented 9 years ago

@muonzoo That was originally my theory , but jediepcserver is working for me on one of my yosemiteosx computers even with the version with the "-final0" suffix, so I am not entirely convinced that that is the issue.

@syohex Why switch from >= to ==? seems most appropriate to me "jedi>=0.8.1".

syohex commented 9 years ago

(I do not know Python version numbering and version number comparison well. I may be wrong.)

Why switch from >= to ==? seems most appropriate to me "jedi>=0.8.1".

>= comparison causes this issue as @muonzoo says(Because 0.8.1-final0 is invalid Python version number). So we should not use >=.

I'll replace == with >= in the future if valid version jedi is relased.

muonzoo commented 9 years ago

@syohex writes:

I'll replace == with >= in the future if valid version jedi is relased.

This might help, yes. I will try a clean install once this is done to see if the problem still exists / can be recreated by reverting.

tbekolay commented 9 years ago

I applied @syohex's fix manually (by doing $HOME/.emacs.d/.python-environments/default/bin/pip install jedi==0.8.1) and it fixed my jedi.el install. It seems like the right things to do until a version > 0.8.1-final0 is released. This was fixed in jedi's master but until a new version is pushed to PyPI we're at the mercy of pip's incorrect version sorting algorithm.

syohex commented 9 years ago

I have applied workaround patch at #187. Please upgrade and check.

bassu commented 9 years ago

Still the same. It installed -final0 version for me. But doing @tbekolay 's workaround, I was able to install 0.8.1 through pip and then M-x jedi:install-server ran just fine!