Automatically detect if pipenv should be used for linters
#1656
Comments
…se-analysis#1656) When set to true, and the buffer is currently inside a pipenv, GetExecutable will return "pipenv", which will trigger the existing functionality to append the correct pipenv arguments to run each linter. Defaults to false. I was going to implement ale#python#PipenvPresent by invoking `pipenv --venv` or `pipenv --where`, but it seemed to be abominably slow, even to the point where the test suite wasn't even finishing ("Tried to run tests 3 times"). The diff is: diff --git a/autoload/ale/python.vim b/autoload/ale/python.vim index 7baae079..8c100d41 100644 --- a/autoload/ale/python.vim +++ b/autoload/ale/python.vim @@ -106,5 +106,9 @@ endfunction " Detects whether a pipenv environment is present. function! ale#python#PipenvPresent(buffer) abort - return findfile('Pipfile.lock', expand('#' . a:buffer . ':p:h') . ';') isnot# '' + let l:cd_string = ale#path#BufferCdString(a:buffer) + let l:output = systemlist(l:cd_string . 'pipenv --where')[0] + " `pipenv --where` returns the path to the dir containing the Pipfile + " if in a pipenv, or some error text otherwise. + return strpart(l:output, 0, 18) !=# "No Pipfile present" endfunction Using vim's `findfile` is much faster, behaves correctly in the majority of situations, and also works reliably when the `pipenv` command doesn't exist.
|
@elebow Any hopes of you opening a PR of that branch to upstream here? Additionally, it'd be nice to support poetry in a similar way (running literally works the exact same way - |
|
Well, I see @elebow's commit actually checks for a lockfile the same way I considered doing for poetry, so maybe that's a sane route to go down (and has fewer upstream dependencies...) |
…se-analysis#1656) When set to true, and the buffer is currently inside a pipenv, GetExecutable will return "pipenv", which will trigger the existing functionality to append the correct pipenv arguments to run each linter. Defaults to false. I was going to implement ale#python#PipenvPresent by invoking `pipenv --venv` or `pipenv --where`, but it seemed to be abominably slow, even to the point where the test suite wasn't even finishing ("Tried to run tests 3 times"). The diff is: diff --git a/autoload/ale/python.vim b/autoload/ale/python.vim index 7baae079..8c100d41 100644 --- a/autoload/ale/python.vim +++ b/autoload/ale/python.vim @@ -106,5 +106,9 @@ endfunction " Detects whether a pipenv environment is present. function! ale#python#PipenvPresent(buffer) abort - return findfile('Pipfile.lock', expand('#' . a:buffer . ':p:h') . ';') isnot# '' + let l:cd_string = ale#path#BufferCdString(a:buffer) + let l:output = systemlist(l:cd_string . 'pipenv --where')[0] + " `pipenv --where` returns the path to the dir containing the Pipfile + " if in a pipenv, or some error text otherwise. + return strpart(l:output, 0, 18) !=# "No Pipfile present" endfunction Using vim's `findfile` is much faster, behaves correctly in the majority of situations, and also works reliably when the `pipenv` command doesn't exist.
…nters Add python_[linter]_auto_pipenv options for python linters (fixes #1656)
|
Thanks to @elebow, you can now use pipenv for the Python linters if you set |
|
You haven't set a default value for this variable and vim is giving: E716: Key not present in Dictionary: ale_python_auto_pipenv |
|
I thought that was covered by 169a6e2#diff-a5941a5354db7e7a717f0be61ffc56bdR4, but I see that you are right. It seems
I'm not sure whether this is intentional, but I would suggest that If that's not possible, then I suppose the obvious fix is to set the variable in |
|
See #1938. I'll fix it. |
…se-analysis#1656) When set to true, and the buffer is currently inside a pipenv, GetExecutable will return "pipenv", which will trigger the existing functionality to append the correct pipenv arguments to run each linter. Defaults to false. I was going to implement ale#python#PipenvPresent by invoking `pipenv --venv` or `pipenv --where`, but it seemed to be abominably slow, even to the point where the test suite wasn't even finishing ("Tried to run tests 3 times"). The diff is: diff --git a/autoload/ale/python.vim b/autoload/ale/python.vim index 7baae079..8c100d41 100644 --- a/autoload/ale/python.vim +++ b/autoload/ale/python.vim @@ -106,5 +106,9 @@ endfunction " Detects whether a pipenv environment is present. function! ale#python#PipenvPresent(buffer) abort - return findfile('Pipfile.lock', expand('#' . a:buffer . ':p:h') . ';') isnot# '' + let l:cd_string = ale#path#BufferCdString(a:buffer) + let l:output = systemlist(l:cd_string . 'pipenv --where')[0] + " `pipenv --where` returns the path to the dir containing the Pipfile + " if in a pipenv, or some error text otherwise. + return strpart(l:output, 0, 18) !=# "No Pipfile present" endfunction Using vim's `findfile` is much faster, behaves correctly in the majority of situations, and also works reliably when the `pipenv` command doesn't exist.
|
Adding the line
|
|
Open a new issue with the output of |
|
@kctong529 I was also having this issue, make sure you have an applicable linter installed inside your pipenv virtual environment, it won't see your globally installed linter. I have and pylint installed globally but it was not installed in my virtualenv, and no other linters we available, |
First mentioned in a comment for #1629
pipenv --venvwill print information that can be used to check if a file is instead of apipenvmanaged project or not. If a file is in such a project, ALE could automatically load executables frompipenvprojects instead. Thispipenvdetection ought to be configurable, and probably off by default, as not everyone will be usingpipenv.The text was updated successfully, but these errors were encountered: