deoplete-plugins/deoplete-jedi

Remove submodule jedi

Closed this issue · 8 comments

deoplete-jedi should not include jedi.
It should use system jedi instead.

Because, it is not easy to follow upstream changes.

Hmm, not sure if this is a good idea..
Shipping/pinning the submodule allows us to target a specific version - otherwise we would need to support older/newer versions, too etc.

I think deoplete-jedi should only supports the latest version of jedi.
I don't want to update jedi in the repository...

I think deoplete-jedi should only supports the latest version of jedi.

Well, you know how long it took (and still takes) to update it for the new environment API?

Also distributions might not have the latest jedi themselves.

I don't want to update jedi in the repository...

What is the problem with that?

Well, you know how long it took (and still takes) to update it for the new environment API?
Also distributions might not have the latest jedi themselves.

But user can install/update jedi by pip3 easily.
neovim package is already installed by pip3. I think it is not problem.

What is the problem with that?

It is very wired instructions.
Please tell the jedi update instructions for me.

But user can install/update jedi by pip3 easily.

And has to check themselves to use the correct version then.

Just git pull --recurse-submodules in deoplete-jedi?
Or do you mean how to update the submodule in our repo?
(`cd rplugin/python3/deoplete/vendored/jedi; ; cd -; git add rplugin/python3/deoplete/vendored/jedi; commit) (I have a function gsmc to add the summary when committing (https://github.com/blueyed/oh-my-zsh/blob/b2d46dbcf1a4e7b012dbc5d38fe7e2ea53be0839/plugins/git/git.plugin.zsh#L735-L752))

jedi has a stable api now, may be use latest one is better

I agree with @Shougo , use the system jedi

Yes system jedi.