Error: jedi-vim fails to load with colorama 0.3.6

[danielmellado]

After deploying a new system, jedi-vim fails to load with the following error message
System: Fedora22

Error detected while processing /home/fedora/.vim/bundle/jedi-vim/autoload/jedi.vim:
line  283:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/fedora/.vim/bundle/jedi-vim/initialize.py", line 22, in <module>
    import jedi_vim
  File "/home/fedora/.vim/bundle/jedi-vim/jedi_vim.py", line 12, in <module>
    import jedi
  File "/usr/lib/python2.7/site-packages/jedi/__init__.py", line 41, in <module>
    from jedi.api import Script, Interpreter, NotFoundError, set_debug_function
  File "/usr/lib/python2.7/site-packages/jedi/api/__init__.py", line 16, in <module>
    from jedi.parser import Parser, load_grammar
  File "/usr/lib/python2.7/site-packages/jedi/parser/__init__.py", line 21, in <module>
    from jedi.parser import tree as pt
  File "/usr/lib/python2.7/site-packages/jedi/parser/tree.py", line 39, in <module>
    from jedi import cache
  File "/usr/lib/python2.7/site-packages/jedi/cache.py", line 32, in <module>
    from jedi import debug
  File "/usr/lib/python2.7/site-packages/jedi/debug.py", line 17, in <module>
    init()
  File "/usr/lib/python2.7/site-packages/colorama/initialise.py", line 37, in init
    wrap_stream(orig_stdout, convert, strip, autoreset, wrap)
  File "/usr/lib/python2.7/site-packages/colorama/initialise.py", line 76, in wrap_stream
    convert=convert, strip=strip, autoreset=autoreset)
  File "/usr/lib/python2.7/site-packages/colorama/ansitowin32.py", line 67, in __init__
    strip = conversion_supported or (not wrapped.closed and not is_a_tty(wrapped))
AttributeError: closed

EDIT
Suggested fix for colorama: tartley/colorama#84

[davidhalter]

Actually loading colorama fails. But this is not a jedi-vim error, because all Jedi does is importing it and calling the init function (look at the code).

Are you using gvim?

[danielmellado]

Hi David,

Thanks for having a look at it. I'm not using gvim, just the regular one. If it helps you my .vimrc and .vim files can be found here: https://github.com/danielmellado/rcfiles

[davidhalter]

Can you try to start Python, import colorama and then use init?

[danielmellado]

Hi David, from within vim, I've tried the following:
:py import colorama
:py import jedi

the latest led to this trace showing, were you refering to this or how are you meant to init jedi_vim from python?

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/jedi/__init__.py", line 41, in <module>
    from jedi.api import Script, Interpreter, NotFoundError, set_debug_function
  File "/usr/lib/python2.7/site-packages/jedi/api/__init__.py", line 16, in <module>
    from jedi.parser import Parser, load_grammar
  File "/usr/lib/python2.7/site-packages/jedi/parser/__init__.py", line 21, in <module>
    from jedi.parser import tree as pt
  File "/usr/lib/python2.7/site-packages/jedi/parser/tree.py", line 39, in <module>
    from jedi import cache
  File "/usr/lib/python2.7/site-packages/jedi/cache.py", line 30, in <module>
    from jedi import settings
ImportError: cannot import name settings

[danielmellado]

After checking, it seems that reverting back to colorama 0.3.5 solved the issue. It was present with latest colorama 0.3.6

[davidhalter]

Hmm that is bad, I have to test this as well.

What you did above is not enough, after calling :py import colorama you have to call the init function of colorama as well.

[tony]

In Neovim, I have a similar error in #523 regarding an AttributeError and closed. They may possibly be related due to vim not giving back a full traceback.

[tarcisioe]

This is what :py3 import colorama; colorama.init() causes on my Vim.

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/tarcisioe/workspace/manta/.venv/lib64/python3.4/site-packages/colorama/initialise.py", line 37, in init
    wrap_stream(orig_stdout, convert, strip, autoreset, wrap)
  File "/home/tarcisioe/workspace/manta/.venv/lib64/python3.4/site-packages/colorama/initialise.py", line 76, in wrap_stream
    convert=convert, strip=strip, autoreset=autoreset)
  File "/home/tarcisioe/workspace/manta/.venv/lib64/python3.4/site-packages/colorama/ansitowin32.py", line 67, in __init__
    strip = conversion_supported or (not wrapped.closed and not is_a_tty(wrapped))
AttributeError: 'vim.message' object has no attribute 'closed'

Sounds similar (the same, actually) to what @tony gets in his Neovim. I ended up having jedi-vim fail whenever I was working on a project that had pylint installed, because pylint depends on colorama>=0.3.5, and so I end up with 0.3.6. A friend of mine confirmed that replacing 0.3.6 with 0.3.5 fixes the issue and is enough for both jedi and pylint to work as expected, but doing this manually for every virtualenv I create is surely non-optimal.

Thanks for looking into it :)

[blueyed]

The problem can be reproduced using:

vim -c 'VirtualEnvActivate' -c 'py import colorama; colorama.init()'

So, you need to have colorama 0.3.6 installed - and activated your virtualenv.

I only have colorama 0.3.3 (Arch is not up-to-date in that regard), and do not activate my virtualenvs (jedi-vim (Git master) picks up $VIRTUAL_ENV by itself).

[blueyed]

@tarcisioe
You are using Vim, and not Neovim, right?

@danielmellado
You are using Neovim, right?

[blueyed]

I think I have the fix for colorama: tartley/colorama#84

[tarcisioe]

Exactly, problem occurs on both, I am using Vim 7.4. Friend of mine uses Neovim and faced the same problem, just as @tony.

[davidhalter]

@blueyed I'm a bit confused by all the colorama related issues. Is this now related with neovim or is it really a colorama issue (and not something that would occur in say emacs)?

What action would you suggest? Should we wrap the colorama import in Jedi, to catch any Exception that it throws while initializing?

[blueyed]

@davidhalter
Colorama issue, which expects something on a stream, that Vim does not provide.
Neovim fixed it by providing this property - so it happened there before, but is fixed in Git.

catch any Exception that it throws while initializing

Not sure - would be a short term fix only - but maybe wrap the imports there altogether.

Also the tracebacks should be better reported (there's an issue for that).

[danielmellado]

@blueyed no, I was using normal Vim

[blueyed]

@danielmellado
Can you please check if downgrading colorama to before 0.3.6 fixes it for you?

[danielmellado]

Downgrading to 0.3.5 makes it work again ;)
El 25/1/2016 8:27 p. m., "Daniel Hahler" [email protected]
escribió:

@danielmellado https://github.com/danielmellado
Can you check if downgrading colorama to before 0.3.6 fixes it for you?

—
Reply to this email directly or view it on GitHub
#522 (comment)
.

[davidhalter]

Latest Jedi linter branch solves this issue. It just ignores all exceptions coming from colorama's init().

[blueyed]

@davidhalter
Should we update the submodule then?

[davidhalter]

Hmm I don't know. We could do that. But maybe it's better to wait for Jedi?

I guess it's not a bad idea to have the same submodule branch as the current pip version.