mirror of
https://gitflic.ru/project/openide/openide.git
synced 2026-02-05 16:36:56 +07:00
a9a8ab00ef
This is a followup for DS-4508. The issue was caused by the fact that intellij.python.helpers content is copied using NIO, and to make it visible for VFS we need to perform refresh of the latter. Without it, PyTypeShed.directory property cannot find the Typeshed root and is initialized to null. Then, PythonSdkUpdater.buildSdkPaths is unable to locate SDK-specific Typeshed roots and set the corresponding interpreter paths on SDK update. The problem is that VFS refresh requires a write action and PyTypeShed.directory is accessed under a read action (e.g. via PyTypeShed.INSTANCE.isInside in PythonLanguageLevelPusher), so performing an explicit refresh would cause a deadlock (not to mention that copying files under a read action is generally concerning). The easiest way to address that is just to resolve to these stubs directly inside the distribution, as before, not triggering copying them. Such stub files are not executable by the interpreter and, thus, don't cause the problems with .pyc files corrupting the IDE installation, so it's safe to leave them there. For the time being, Typeshed and python-skeletons are still copied together with executable helpers, though, but these copies are effectively ignored by code analysis, It's only not to break the implicit contract of PythonHelpersLocator.getHelpersRoot, from which it's expected that the entire content of intellij.python.helpers would reside in the returned directory. A proper solution would be to move all type hinting stubs from intellij.python.helpers to a dedicated module, excluded from copying, but it needs to be further discussed and is risky right before the release. GitOrigin-RevId: 2470cc110faa8286c44be2102aacc48893ea7ea9