1. Delete `intellij.python.community.impl.xml` (move content to `PythonCore` plugin). It is necessary to fix incorrect dependencies: `PythonCore`, `Pythonid` include the same module.
2. Fixed dependencies: if some plugin/module needs Python core functionality, then it should depend on `PythonCore`.
Co-authored-by: Vladimir Koshelev <Vladimir.Koshelev@jetbrains.com>
Merge-request: IJ-MR-136158
Merged-by: Egor Eliseev <Egor.Eliseev@jetbrains.com>
GitOrigin-RevId: ce9ed4c17f601ee1ca2b6cf608f4e30fdac1d879
Layout:
JPS modules
`intellij.python.community`
`intellij.python.community.impl`
`intellij.python.parser`
`intellij.python.psi`
`intellij.python.psi.impl`
`intellij.python.ast`
use package `com.jetbrains.python`
and go to `intellij.python.community.impl` v2 module
JPS module
`intellij.python`
uses package `com.intellij.python.pro`
and goes to `intellij.python/pro` v2 module
Both v2 modules (along with lots of others) come with
`PythonId` (prof) or `PythonCore` (community) plugins
DS bundles `intellij.python.community.impl`
Idea and other Mini IDEs get `PythonCore` or `PythonId` plugin that bundle modules for Idea and mini IDEs
GitOrigin-RevId: 98f418c52d90d51b9adf3250c561f2c36c767e2d
Completion contributors already wrapped in `DumbModeAccessType.RELIABLE_DATA_ONLY.ignoreDumbMode` in `CompletionProgressIndicator#calculateItems` so we don't need any extra-wrappings to prevent IndexNotReadyException
(cherry picked from commit 83c120ed2502474f3ddcfa2a52c6e9552d02e55e)
IJ-CR-14512
GitOrigin-RevId: e806ecb879708a75a8e7f544ea6d16a0648ca069
Targets API implementation for Run Configuration is enabled by the registry key "python.use.targets.api.for.run.configurations".
GitOrigin-RevId: d5a70ae8951d14689d079b54b32f7050471ffdb5
Hence staying closer to the original implementation that didn't distinguish
Sphinx and Docutils specific run configuration internally. It may be beneficial
to return the exact run configuration types once they start to actually differ
in some way or become applicable in some overlapping contexts.
GitOrigin-RevId: 8104c4949dea558ca4199ad06172d1ce9fb1ab8c
The main problem with them is that due to an odd design decision they both share
the same configuration type -- RestRunConfigurationType, and it doesn't quite fit in
this newer typed API, e.g. isConfigurationFromContext() can receive a configuration
instance of a wrong type (DocutilsRunConfiguration for SphinxConfigurationProducer and
vice-versa) due to it, producing a CCE at runtime. I employed a workaround already
used in Python testing run configurations sharing the same problem. Namely,
overloaded getConfigurationSettingsList() to additionally check that instances of
RunnerAndConfigurationSettings with RestRunConfigurationType type actually
correspond to run configurations of the proper concrete class.
Note that setupConfigurationFromContext can also receive a run configuration of a wrong
type but in reality it doesn't happen since Sphinx and Docutils run configurations are
applied to different contexts -- directories and individual .rst files respectively.
GitOrigin-RevId: 15fbb90917edd68e6f29b696c527ff04d4eed433
