Poetry/pipenv support?

[Lilja]

It would be amazing if this plugin could support pipenv/poetry!

I skimmed through the repo and I think the relevant code is this part

Perhaps this code could check if pyproject.toml or Pipfile exists and then run poetry run python <cmd>/pipenv run python <cmd> instead of python <cmd>?

EDIT: For the record, I found this repo through google/vim-coverage. When running :CoverageShow coverage.py import coverage can't be found since it loads this script through this invocation led me that this should be a feature to this repo and not the google/vim-coverage.

[dbarnett]

Oh, I wasn't getting how python package dependencies were relevant until I saw the specific example with coverage. But are you imagining cases where there's no system-wide install of python & coverage, or what?

[Lilja]

But are you imagining cases where there's no system-wide install of python & coverage, or what?

Yes:

[malcolmr]

For running the right Python, this might be able to be worked around with a ~/bin/python (or whatever) in your PATH (or making the command overridable inside Maktaba, yes).

However, that still leaves the problem that maktaba#python#Eval only runs binaries as a fallback if Vim itself doesn't have Python support, and that seems like the more-likely case in general.

I'm not familiar with poetry, but would it make sense to run Vim itself in an environment where python -m coverage works? (i.e. for virtualenv, this'd be running something like source venv/bin/activate first).

In that case, everything should just work, whether we use Vim's native Python support, or fall back to running a python binary.

[Lilja]

I think poetry run <command> is just syntax sugar for source ~/some/venv/in/a/folder/near/you/activate && <command>.

As a side note, I've recently began using coc.nvim and coc-pyright which is a LSP that has some nice features like knowing if the workspace/project uses some kind of dev tool like poetry/pipenv. I feel spoiled/privileged to not having to know about if vim's environment is properly sourced through a virtualenv.

As a workaround for now, I added petobens/poet-v to my vimrc and ran :PoetvActivate. That loaded the proper python environment into vim and I'm able to run :CoverageShow coverage.py inside the project and not get an error.
The workaround is not amazing, since it would require a manual :PoetvActivate every launch. I think it would be great if there were tooling to sort of automatically know what kind of environment a project is in and could set the provider from vim-coverage and be able run coverage-commands more smoothly!
Maybe this is out of scope for this plugin and should be done/thought of elsewhere?

[dbarnett]

Looks like another option would be to run poetry shell or source $(poetry env info --path)/bin/activate in the terminal before starting vim. Or you could set up an autocmd to run :PoetvActivate for you from the vim side.

As a maintainer I'm a little concerned about adding too much magic at this level, but specifically for the vim-coverage case I can see some justification for using the same coverage install you're using for the project, since people have run into versioning issues from accessing the same coverage data with different system/project versions of coverage.py. The snag is I think it'd be brittle to introduce a dependency on CWD for detecting which project settings to use. It could in theory detect based on which buffer you're showing coverage for, but that would require changing the library interface and doesn't sound appropriate for ALL existing python we invoke to try to use per-project versions of python & deps. Might be a reasonable vim-coverage feature request, but a pretty effort-intensive one to implement if so.