This repository was archived by the owner on Apr 14, 2022. It is now read-only.
Mark files in .venv as library files to avoid reindexing #1207
Description
It would be nice if files in .venv folder are considered as library files, so as they won't be re-indexed when user files changes. We are using PIPENV_VENV_IN_PROJECT to store virtual environment directory directly inside our workspace directory.
Or an extra configuration like autocomplete.extraLibPaths would make configuring project paths more flexible.
Activity
jakebailey commentedon Jun 17, 2019
Can you be more specific? This should already occur. We get the details of the interpreter from it directly, and treat anything it reports as library code during our analysis. What do you mean by "re-indexed"?
lephuongbg commentedon Jun 17, 2019
We are using docker volume to share code between host and container. That means the paths that python interpreter reports are container's paths, not host's paths (We have a bridge script that uses
docker execto make it look like a local python interpreter).We can set
extraPathslike following:but on any changes to
apifolders, all files insite-packageswill also get "reindexed", or that's what I thought the "Reloading modules" step did.Our site-packages folder is of medium size, so it take a while along with 100% cpu everytime "Reloading modules" starts.
jakebailey commentedon Jun 17, 2019
Those two
.venventries shouldn't be required if the interpreter is already activated/chosen. Do things not work if those aren't present, or can you remove them and have things still work? (We ask the interpreter for that information already, so you should not have to specify those by hand, and I think it might actually break things to manually specify an interpreter-owned directory, but I'm not sure.)Reloading modules happens when we detect that there has been a package install; in that case we have to "reload modules" and start the analysis over again, since the existence of a new module has very broad impacts.
It might be the case that it's happening too often and triggering on user files (and I know there are some issues with our file watching, I have to file an issue on that for investigation).
Is this VS Code Remote, or a custom solution? https://code.visualstudio.com/docs/remote/containers
lephuongbg commentedon Jun 17, 2019
This is a custom solution, not vs code remote, as I said we have a "bridge script" to act as a local python interpreter, but in fact passing commands to container's python using
docker exec.The problem is the interpreter will report container paths, not host paths. Example:
/var/task/.venv/lib/python3.7. That's why we have to manually add these paths like above.VS Code Remote looks promising but we only share a portion of the code (the
apifolder) to the python container, and we have multiple other containers, each mount a different folder. This workflow seems not yet easy to integrate with Code Remote.jakebailey commentedon Sep 19, 2019
#1492 fixed our library code watching toggle to be visible again (among other fixes to file watching). If the watching isn't working how you'd like, you can add:
To disable this functionality.