North Year <ny-ml@outlook.com> writes: > 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). > > Maybe I have a silly solution, > > Since you are using .git, then maybe you can create a .hg, .svn, > or what ever CVS tools other than svn, > in VeryImportantLambda folder, MoreImportance folder, and > RunInCaseOfEmergency folder. > > Then when you visit files in VeryImportantLambda folder, > then project.el will set the project root at VeryImportantLambda, > I think everything would just be fine there. > As long as you donât launch eglot python lsp in the âactualâ project (which > is .git), > which for example is project_root/src/python/main.py > then everything should be fine. Ah, but I'm trying to have my cake and eat it, too: have project.el consider the whole codebase as a single project, but have Eglot use the language server executables from the sub-directories. Putting a dummy CVS file in the subdirectories would fool both Eglot and project.el.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4