Re: Eglot, project.el, and python virtual environments

[Philip Kaludercic]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Hi,
>
> Here's another issue that's technically a emacs.help question, but might
> result in some code/documentation updates, so I'm sending it here.
>
> My main day-job code base is an AWS CloudFormation monstrosity involving
> several Python Lambdas, among other things. Basic project structure
> looks like:
>
> project_root
> ├── .git
> ├── src
> │   └── python
> │       ├── VeryImportantLambda
> │       │   └── .venv
> │       ├── MoreImportance
> │       │   └── .venv
> │       ├── RunInCaseOfEmergency
> │       │   └── .venv
>
> I'm using the python-lsp-server python package in each Python
> subdirectory, and the key is that each of those directories is a virtual
> environment that needs to stay isolated from the others. Each has
> different packages installed, and in some cases even the Python versions
> are different (though I'm trying to get rid of that).
>
> When I was using lsp-mode this wasn't difficult, because lsp-mode and
> project.el are essentially orthogonal: if I visited a python file in a
> given lambda directory, I could use `pyvenv-activate' to activate that
> environment, and then the `lsp' invocation would confine itself to
> python files within the environment. Project.el just provided
> project-wide navigation.
>
> Now I'm trying to move to Eglot, and there is tighter integration
> between Eglot and project.el. Turning on Eglot in one lambda starts the
> server for all Python libraries in the whole project, not just the
> current environment. I looked into constructing my own version of the
> call to `eglot', but it is tightly tied to a project, all the way down.
>
> Is anyone else handling this situation? Any suggestions how to make it
> work?

I am not certain if this is the right tool for the job, but have you
taken a look at `buffer-env'?  I have used it in combination with Eglot,
but the problem I was tackling was not the same as yours.

> Thanks,
> Eric