There are lots of methods that return "default value" if provided data can't be parsed. It leads to errors and misunderstandings
Signed-off-by: Ilya.Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: 0736c91c91e1e6990d23169a492ec408f7299830
It is used by virtualenv creation and we want venv to be a separate module
Signed-off-by: Ilya.Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: 3b394047320ee149189007321475711e92ca3c17
No need to have a separate class
Signed-off-by: Ilya.Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: 9af33f30bbab9a85609c0c6536cb3120347fa20b
It is always `--version` and `Python [version]`, no need to have virtual overridable methods.
One doesn't need to know the flavor to get a python version.
(cherry picked from commit 63b16768f1dd299cb4cefb5fd935c44614d6ffb6)
IJ-CR-151990
GitOrigin-RevId: ebc2eb5428c10048cc6f17a6e5c99632b3f7d2cc
`isValidSdkHome` works for local paths only.
We must use `sdkSeemsValid` instead: it is aware of remote interpreters and usually ignores them if can't validate
GitOrigin-RevId: 31b42e14518f5a8f7a69ba35e50353f4f4894f42
In PY-75549 we might need to search for pythons after python installation. Windows flavor caches paths, so nothing found even after installation. We need to reset this cache.
GitOrigin-RevId: 2e2d22d8a07fb06f26875058882fad3cbdfda05b
Deprecated APIs which still have internal usage are marked as internal to ensure that new external usages won't appear.
GitOrigin-RevId: 09818b884851d7b768f8ee0f356f982e79b46ed9
All "implicit" locks are removed from the platform, so we need to call read/write action explicitly (which is a right thing to do in any case).
GitOrigin-RevId: 290788bc78e39ca42f7d0f14ae4ccd16dd315ce7
Implement version tracking for Python specified in pyproject.toml files.
Validate base interpreters using a Python version from pyproject.toml.
Merge-request: IJ-MR-142231
Merged-by: Egor Eliseev <Egor.Eliseev@jetbrains.com>
GitOrigin-RevId: ddd685240b6d58ef8d2e6c5668c89c96d8992d27
- refactored NPW to use target-specific model
- creating interpreter through widget reuses the same UI (can be turned off by python.unified.interpreter.configuration)
- interpreter discovery and virtualenv creation using Targets API
- no more PyDetectedSdk in dialog
(cherry picked from commit 581b2d40254d26f02eb3aa61bc2e842854b87a3e)
IJ-MR-140986
GitOrigin-RevId: be29188304882ef5f0fb88bb60c538714a2d8746
`getFlavor(@Nullable String sdkPath)` was used, and it detected the first flavor that is reports `isValidSdkHome`.
Somehow `UnixPythonSdkFlavor` stayed before `VirtualEnvSdkFlavor`.
We now sort them to make platform independent go first (as platform-dependent are always there).
We also use a separate method `tryDetectFlavorByLocalPath` not to use a deprecated one.
GitOrigin-RevId: ee7010e2b4a51d8447bd57264b2ce85af4ea1199
1. `PythonHelpersLocator` is an API to get helpers. It is aware of PyCharm Community helpers but also aware of some EP that provides additional helper paths.
2. EP implementations for PyCharm Prof and Jupyter that provide additional (prof) helpers.
It will help avoid problems with which Locator to use from Professional, Community or Jupiter plugins.
Merge-request: IJ-MR-140027
Merged-by: Egor Eliseev <Egor.Eliseev@jetbrains.com>
GitOrigin-RevId: c7c34f323247002699866f12f6ff5a08cf6a18ff
