Use `ExecService` `api.kt` to exec any binary and extensions from `execService.python/api.kt` for python-specific things (i.e helpers)
GitOrigin-RevId: bb217798a9d1ee886c4b12220ec1f66a5ef08336
* use the same UI in IDEA for local SDKS as currently PyCharm has, removing redundant code
Merge-request: IJ-MR-164681
Merged-by: Vitaly Legchilkin <Vitaly.Legchilkin@jetbrains.com>
GitOrigin-RevId: fe26897837f41dd2f3b23a328d2a9098ad388e37
This is needed to have an explicit dependency on the backend in it (IJPL-188916), and also to convert XML modules it depend on in content modules as well.
The new module is registered in common-ide-modules.xml to include it in all IntelliJ-based IDEs as before.
A plugin alias 'com.intellij.modules.spellchecker' is introduced to allow adding dependency on the new module without using a v2 'dependencies' tag. Existing plugins which depend on intellij.spellchecker are updated to have an explicit dependency. The change shouldn't affect external plugins which use classes from 'intellij.spellchecker' because the new module will be automatically added to their dependencies.
'lucene' and 'ai.grazie.spell.gec.engine.local' libraries which were included in the main classloader of the core plugin before due to this module are temporary included in distribution of intellij.ml.llm, intellij.grazie and intellij.searchEverywhereMl plugins. This will be fixed by converting these libraries to content module in next commits.
GitOrigin-RevId: aa746fea2f6fd044cf0eaabd6589fce89133eee9
- Added a top-level "Python" settings group in PyCharm
- Moved all Python-related settings pages under this group for better discoverability
- Retained original registration of settings pages so they remain in their default locations in non-PyCharm IDEs (e.g., IDEA with Python plugin)
- For application-level configurables: relocation handled in PyCharmCorePluginConfigurator.execute
- For project-level configurables: relocation handled in PyCharmProjectConfigurableStartupActivity.execute
- Introduced two configuration steps to support the relocation mechanism
GitOrigin-RevId: 4db5885cb2f0af0443fb476c376873d847cef2da
Allow external plugins to provide custom Python runners by removing the ordering attribute.
This change enables plugins to override default Python runner behavior by registering
their own implementations without being affected by the fixed ordering.
Merge-request: IJ-MR-162975
Merged-by: Timur Malanin <timur.malanin@jetbrains.com>
GitOrigin-RevId: 8328a4d696cfdd91882bcb386eb204f67cd4f434
* PythonRepositoryPackageSpecification replaces existing PythonSimplePackageSpecification/PythonPackageSpecification:
* sealed class PythonPackageInstallRequest added for package installation. Almost all managers are able to work only with simple specifications except pip. Pip could install packages by location uri or all packages via "pip install" without package name specification.
* versionSpec type was changed from String to PyRequirementVersionSpec
* move buildPackageDetails from PythonRepositoryManager to PyPackageRepository, to avoid "is CondaPackageRepository" abstraction leaks.
* make the repository field in InstalledPackage optional (might be installed packages without any repository, installed by url). Got rid of PyEmptyPackagePackageRepository / EmptyPythonPackageDetails.
* CondaRepositoryManger cleanup, there is no any custom logic there except own caches.
* fix CompositePythonPackageManager leaks:
- keep only distinct repositories from all managers (PyPI was duplicated)
- await for all launchManagerRefresh() calls, previously it was not awaited and has returned empty packages on refreshCaches()
Merge-request: IJ-MR-162074
Merged-by: Vitaly Legchilkin <Vitaly.Legchilkin@jetbrains.com>
GitOrigin-RevId: 83cfce57b12cd90a0a274bf2d70ecedc1b99d05d
* PythonPackageManagerJobService.kt added to manage tool jobs
* Base PythonPackageManagerAction.kt was added to cover all python package manager actions
* Implementations for Poetry / Hatch / uv
* Poetry pyproject.toml watcher was removed (replaced with poetry actions)
GitOrigin-RevId: 0bbc5a7802826674140ca1c80be27b6cd7d0f59e
DO:
For upper-level (public) API use `PyResult`.
(Optionally) for low-level APIs inside your modules use python `Result<S, E>`.
Represent errors as `PyError` whenever possible.
Report `PyError` to `ErrorSink` at the top of your code.
DON'T:
Use `kotlin.Result`
Use `PyExecutionException`
Use any exception to represent user errors.
GitOrigin-RevId: 4ecf69e1fae8be9192cd33b90e0147c725a98964
