Skip to content
This repository has been archived by the owner on Apr 14, 2022. It is now read-only.

Fix editable installs when using extraPaths/PYTHONPATH #1183

Merged
merged 3 commits into from
Jun 7, 2019

Conversation

jakebailey
Copy link
Member

@jakebailey jakebailey commented Jun 7, 2019

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

"python.autoComplete.extraPaths": [
    "./src"
]

Or a more complicated:

"python.autoComplete.extraPaths": [
    "./package_a",
    "./package_b",
    "./package_c"
]

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 extraPaths recommendation somewhere. (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.

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.

@r-bit-rry
Copy link

you can throw in this issue also to the fixed: 5838

@jakebailey
Copy link
Member Author

I don't think we can close issues on other repos via PRs here without some extra config (plus after merge I don't think editing messages will cause issue closing), but if this fixes your issue then feel free to close it and point to this PR.

@r-bit-rry
Copy link

Yesterday I got the latest daily 0.3.22 but the problem seems to remain.
can you tell me if this was included in any release?

@jakebailey
Copy link
Member Author

This has been included for a while now. Please file an issue with your info.

jakebailey added a commit to jakebailey/python-language-server that referenced this pull request Nov 1, 2019
* Allow interpreter paths to be reclassified as user code if specified in user search paths

* log raw search path results only in verbose mode

* update TROUBLESHOOTING
@alan23273850
Copy link

Hi everyone! I've found that "python.autoComplete.extraPaths": [ "./**" ] is a very simple solution since the double stars means any sub-folder in Linux!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.