[WIP] Add support for detecting venvs from pipenv and poetry projects

[truls]

This PR adds support for detecting if a project is managed using either poetry or pipenv and configuring pyright to use the venv and python interpreter created by those tools.

I have been using this code for a while without problems and I think it's extremely useful. However, there are a couple of problems with the code, thus the WIP tag:

• The synchronous subprocess invocation causes emacs to freeze briefly when opening a file from a python project for the first time. Is there a way to do this asynchronously?
• The code currently detects a pipenv project if Pipfile exists in the project root and pipenv is found in PATH. Likewise, poetry is assumed if pyproject.toml is found in the project root and poetry is found in PATH. This naive approach misses several obvious cases, but I wonder if there is a method or even need to make the detection mechanism more accurate or if it's better to add a customization variable that overrides the detection?

I'm looking forward to your feedback!

[ahmed-shariff]

Thanks for the PR man. I've trying to sort this out and it's been driving me nuts, lol.
Does this load the packages from the venv itself? Following the configuration of pyright, If my understanding it correct, setting "python.venvPath" alone is not enough. We need to set the "python.venv" as well?

I tried doing that with something along the lines of the following and I am still unable to get the packages from the venv loaded:

(lsp-register-custom-settings
  '(("python.venvPath" "/")
    ("python.venv" (lambda () (file-relative-name (or (lsp-pyright-locate-venv) (poetry-get-virtualenv)) "/")))))))

[truls]

Thanks for looking at the PR!

So, if I understand you correctly, pyright isn't loading packages from the project venv when you use the current code? Which platform are you on?

I think the python.venv setting overrides the load paths that pyright gets from sys.path of the python interpreter used by the project. I'm not sure that you want to do that?

[ahmed-shariff]

So, if I understand you correctly, pyright isn't loading packages from the project venv when you use the current code? Which platform are you on?

yes, it doesn't load the packages from the project env. I am not sure if this is the correct way to test this, but I am checking this by running lsp-find-definition on one of the imports.

Looking at the pyright implementation itself:

    if (configOptions.venvPath !== undefined && configOptions.venv) {
    .
    .
    .
            const sitePackagesPath = findSitePackagesPath(fs, combinePaths(venvPath, libPath), importFailureInfo);

I thought pyright looks for the site-packge when both venv and venvPath are provided, right?

[vakker]

@truls this looks interesting. Have you had issues like #66? Your PR might actually resolve that.

[deifactor]

It'd also be good to look at the $VIRTUAL_ENV environment variable if that's set; my direnv + pyenv setup sets that.

I think in general the way lsp-pyright finds the venv and python should be rethought a bit, since right now it silently assumes a default that's unlikely to be correct for most people.

[flexagoon]

Hi, is this PR stale? I really need this feature.

[ghost]

I created a PR to allow us to more easily configure how we choose the python executable - #89 - I wonder if we would be able to build on that to better support pipenv and poetry. For me personally all I need is for the default to be the python executable and ignore any .venv directory

[wyuenho]

Please don't complicate virtualenv discovery in this project, just keep it simple with defcustoms as they currently are so people can customize them in the mode hooks or use emacs-pet.

[truls]

I agree that emacs-pet is the canonical solution to this problem and I'm closing this PR now. Thanks for drawing my attention to that project. Adding an example showing how to integrate emacs-pet with lsp-pyright would make sense as using project tools to manage python venvs is a prevalent scenario and lsp-pyright is basically useless OOTB in these cases right now.