[WIP/RFC] Improve selection of environments#836
[WIP/RFC] Improve selection of environments#836blueyed wants to merge 1 commit intodavidhalter:masterfrom
Conversation
|
@davidhalter Using |
|
BTW: I actually wanted to list the virtualenvs and system pythons in a buffer anyway so a user could choose. I think improved environment selection will be a great feature. |
| " ------------------------------------------------------------------------ | ||
| " functions that call python code | ||
| " ------------------------------------------------------------------------ | ||
| function! jedi#use_environment(...) abort |
There was a problem hiding this comment.
Rename to set_environment?
| PythonJedi jedi_vim.set_environment(*vim.eval('a:000')) | ||
| endfunction | ||
|
|
||
| function! jedi#use_environment_for_buffer(env) abort |
There was a problem hiding this comment.
Same as above.
There should also be setters (and getters) for tab- and window-local settings.
| " files?!). | ||
| function! jedi#complete_environments(argl, cmdl, pos) abort | ||
| PythonJedi jedi_vim.complete_environments() | ||
| EOF |
| command! -nargs=1 -complete=custom,jedi#py_import_completions Pyimport :call jedi#py_import(<q-args>) | ||
|
|
||
| " Transfer bang into current buffer number. | ||
| " TODO: use window instead!? |
There was a problem hiding this comment.
See above - should support global, tab, window and buffer.
| return func_receiver | ||
|
|
||
|
|
||
| # XXX: might use lru cache, given that you can configure it per buffer?! |
There was a problem hiding this comment.
Probably all the caching (and invalidation) should be done by Jedi.
| current_environment = (None, None) | ||
|
|
||
|
|
||
| def set_environment(executable=None, bufnr=None): |
There was a problem hiding this comment.
Needs support for tab, window, and bufnr.
Could be scope.
There was a problem hiding this comment.
While you can do that, I don't think this is what most users need/want. The scope most users want to use is probably global, but I'm not against it - I'm just saying that you're probably doing more work than necessary if you use a bufnr scope. :)
There was a problem hiding this comment.
Yeah, it is not really necessary, but a good example for getting the scoping right from the beginning.
More important would be a tab-local setting then I guess.
This is kind of useful in an IDE-like environment where you would work on different projects/venvs in parallel - but yes, it is a bit constructed.
| current_environment = (executable, environment) | ||
|
|
||
|
|
||
| def get_environment(use_cache=True): |
There was a problem hiding this comment.
Add scope here then, too. But it would default to preferring bufnr over window over tab over globals.
| vim.command("return '%s'" % '\n'.join( | ||
| ('%s (*)' if env.executable == current_executable else '%s') % ( | ||
| env.executable | ||
| ) for env in envs)) |
There was a problem hiding this comment.
TODO: display more information (after the name, similar to the currently selected one), e.g. the version.
|
Updated to use davidhalter/jedi#1176. |
|
@davidhalter |
blueyed
changed the title
|
|
||
|
|
||
| def complete_environments(): | ||
| envs = get_known_environments() |
There was a problem hiding this comment.
Especially since the latest changes we need to cache those, otherwise this is going to be very very slow.
|
I like the general direction of this PR. For me personally I have always envisioned a "list environments" feature where you could then choose which environment you would want to use. However this is a feature that might also be interesting for some people! |
This is taken out of davidhalter#836.
Improve JediDebugInfo for envs This is taken out of #836.
Codecov Report
@@ Coverage Diff @@
## master #836 +/- ##
==========================================
- Coverage 47.68% 46.11% -1.57%
==========================================
Files 3 3
Lines 799 798 -1
Branches 164 165 +1
==========================================
- Hits 381 368 -13
- Misses 384 396 +12
Partials 34 34
Continue to review full report at Codecov.
|
| # XXX: create_environment is not deterministic | ||
| # (https://github.com/davidhalter/jedi/issues/1155) | ||
| # jedi.create_environment(executable, safe=False) | ||
| environment = jedi.api.environment.Environment(executable) |
There was a problem hiding this comment.
Just for information, I had to comment this line and use environment = jedi.create_environment(executable, safe=False) instead to get it working.
I'm using python3.7 with pyenv.
There was a problem hiding this comment.
@Fenkiou
Thanks for trying this.
Did you get an error before? ("'executable=%s is not supported: %s.'")
If so, what was the message?
There was a problem hiding this comment.
Nope the message was this one:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Users/alex/.vim/repos/github.com/davidhalter/jedi-vim/pythonx/jedi_vim.py", line 177, in set_environment
environment = jedi.api.environment.Environment(executable=executable)
TypeError: __init__() missing 1 required positional argument: 'path'
But in fact, I didn't run git submodule update when checking out your branch, everything is working correctly without any change! Sorry for the noise.
|
Hi @blueyed. I've recently started using pipenv to manage my python applications and was wondering if there is an easy way (either with this PR or with the current jedi/vim-jedi version) to have jedi automatically use a pipenv environment if one is available in the current directory. I was thinking of something along the lines: let pipenv_venv_path = system('pipenv --venv')
if v:shell_error == 0
let jedi_venv = trim(pipenv_venv_path)
else
let jedi_venv = use_system_python
endifthat would triggered every time python buffer is read. Do you think this is possible? If so, can you give a few pointers on how to implement it? Thanks!! |
pipenv is slow in general, and |
|
Rebased, without the updates to jedi/parso which I assume have landed already. |
I gave it a shot and it seems to work. My main problem (with your changes and with vim and venvs in general) is how to disable a virtual env: Can you reproduce that? Is there a workaround? Thanks! And sorry for the late reply. |
|
Just tested this a little bit, seems to work fine (the patch didn't apply right away, but simple enough to fix). Thanks 😄 🎉 🥇 The autocompletion for For anyone reading this - it's only the auto-completion I'm talking about. You can provide the correct path to It's great as it is though, I could easily enough provide my own wrapper around |
|
@aliceh75 As for completing from certain paths there is |
Unletting Mixing it with
It should work OK when only sticking to Maybe jedi-vim could be made smarter about handling |
davidhalter
left a comment
davidhalter
left a comment
There was a problem hiding this comment.
I feel like the API here is definitely going into the right direction.
I've always had a feeling that we should add something like a quickfix window where you could select the "new" environment. get_known_environments will make that possible.
I feel like completing the environments might work, but it's a bit risky since it takes a lot of time. Not that I'm saying it's a bad idea to use completions, it's just slow (as I noted in a comment).
Otherwise good work. I definitely like where this is going!
| def get_known_environments(): | ||
| """Get known Jedi environments.""" | ||
| envs = list(jedi.api.environment.find_virtualenvs()) | ||
| paths = vim_eval("g:jedi#environment_paths") |
There was a problem hiding this comment.
If paths is empty, it should probably be the current directory. Or does that not make sense?
|
@petobens Just FYI we won't support a combination of Jedi/vim-virtualenv. That will break in a lot of ways for sure. There's so many potential issues there. Also it will really not be needed once this stuff is finished. |
|
@blueyed having problems with jedi and virtualenvs too, just discovered this PR here. (in my case, completion with packages virtualenv works perfectly, but goto-definition not, $VIRTUAL_ENV is set correctly) |
|
@syphar sure, give it a try. (I've just rebased it on master) |
|
I'm been using this with my poetry/pipenv plugin petobens/poet-v#2 and it seems to work great so far. Thank you!! |
|
@petobens |
|
One minor question: is there a way to disable enviroment usage and point jedi to use the global python executable? The current way I'm doing it is |
|
@petobens This is already the default, you don't have to do this. Default environment selection changed quite a bit over the last year. At the moment it's pretty much what you are already doing. |
|
Ok. Thanks |
|
@blueyed if this is not moving forward yet can you rebase on latest master? Thanks!! |
|
Thank you! |
|
@blueyed Sorry for asking this again but can this branch be rebased on latest master? Also any idea/plans for this to be actually merged (i've been using it for a while now without any issues AFAICT)? |
|
Thanks! |
|
@blueyed I feel like this change is obsolete with my latest changes. I was heavily inspired by your changes here, but ultimately decided no to reuse the code for various reasons. I would therefore probably close it or do you think that there is still stuff in here that needs to be kept? |
7 participants
Includes/uses davidhalter/jedi#1108.
TODO:
g:jedi#force_py_version(s:init_python: handle g:jedi#force_py_version again #834 (comment))