Skip to content
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

Open
lephuongbg opened this issue Jun 17, 2019 · 5 comments
Open

Mark files in .venv as library files to avoid reindexing #1207

lephuongbg opened this issue Jun 17, 2019 · 5 comments

Comments

@lephuongbg
Copy link

lephuongbg commented Jun 17, 2019

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.

@jakebailey
Copy link
Member

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
Copy link
Author

lephuongbg commented 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 exec to make it look like a local python interpreter).

We can set extraPaths like following:

["./api", "./api/.venv/lib/python3.7", "./api/.venv/lib/python3.7/site-packages"]

but on any changes to api folders, all files in site-packages will 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
Copy link
Member

Those two .venv entries 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
Copy link
Author

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 api folder) 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
Copy link
Member

#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:

"python.analysis.watchSearchPaths": false

To disable this functionality.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants