This repository was archived by the owner on Apr 14, 2022. It is now read-only.
Fix editable installs when using extraPaths/PYTHONPATH #1183
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #989.
Fixes #1013.
Closes #1085.
Closes #1099.
Fixes #1118.
Fixes #1137.
Closes #1169.
Updates #537. (The original use case should have both pth and a config file, but supporting
pth
in general needs to be reexamined.)Updates #814. (Verify with @karthiknadig that this fixes the vendored dirs in ptvsd.)
Updates #918. (Fixes some issues in that thread, but does not add egg support; could be closed in favor of #196.)
Packages installed as editable show up in the "interpreter paths", as the interpreter's setup has been modified to show that package. Before, when we saw an item in both the interpreter and user search paths lists, the interpreter path won.
Now, if the user search paths explicitly list something, then it will first be removed from the interpreter search path (and potentially be re-added if it's found to live outside the workspace). This should mean that the old behavior of treating code outside the workspace as library code will remain the same, but editable installs will now work with extraPaths. Additionally, I've added some logging which will print the "final" search path classification, as printing it early hid the core issue from view.
After this PR, the current way to handle workspaces where the imports are not derived from the workspace root is to explicitly designate which paths are import roots, i.e.:
Or a more complicated:
We should look into creating distinct configuration options that allow us to distinguish this, rather than having to apply a heuristic to
initializationOptions.searchPaths
.Additionally, we should be documenting this(Done in this PR.) Potentially, add to the VSC extension UI, or a popup if we detect that some import could be fixable with this method.extraPaths
recommendation somewhere.Solving this issue automatically may not be possible, however in all of the cases documented in #1169, users have opened the directive above their actual import roots; it may be possible to simply iterate through this list of things and add them as roots, but that may produce bad side effects.