Removed unnecessary namespace separators in feature providers to simplify definitions. Updated the ML model dependency from "lilac-coua" to "coral-panda" with corresponding artifact references. Adjusted typing feature keys for consistency.
(cherry picked from commit ef5561233dee5c13b7ad304bfa0fd5399d30eafd)
IJ-CR-156068
GitOrigin-RevId: c49ff1b73a56009e1db24a0e993fa6cc52a0d87f
It implements the full semantic version 2.0.0 specification and provides the ability to parse, compare, and increment semantic versions along with validation against constraints (C) author
+ add io.github.z4kn4fein:semver-jvm:2.0.0 as library on project level
+ switch module-local dependency for RustRover to the project-level.
+ add to the python.core plugin as a dependency
GitOrigin-RevId: f95154ba8d99b91687bd02fc952281aa5f05f0a5
Namely, whenever there is a `sys.path` entry or a user-added path pointing
to the root of another project module, instead of configuring a source root
for it, we now set up the corresponding module dependency and save it
as a "transferred root" in additional data alongside extra directories
configured as source roots.
This POC solution has a number of limitations:
- A module dependency is set up only if the corresponding module
has already been added to the project. Modules are added using
"Attach to project" as before.
- Since detecting modules is happening on the interpreter introspection
phase, if project A depends on project B, once the module B is actually
configured as an IJ module, one needs to restart SDK update for project
A's SDK to detect the dependency.
- Detecting module dependencies this way requires having a configured
project interpreter for each dependent module, which might not be
practical for large projects, such as grazie-ml.
- It doesn't play well with manual editing of module dependencies in
settings.
Overall, this workaround works well with an existing multi-module project,
where a new subproject with its own SDK and module dependencies needs to
be added as an IJ module. But ideally we need to rely on the actual
project configuration files, not on runtime values of `sys.path`, and
make the workflow of configuring all project modules at once simpler.
A registry key "python.detect.cross.module.dependencies", disabled by default,
activates the feature.
As part of the feature, I also disabled configuring source roots for
`sys.path` entries not belonging to the current module. It leads
to a confusing situation where multiple modules have a content root
(with a single source root) pointing to the same directory in another
module. In a multi-module setting, it can happen if several modules
depend on some subproject that has not yet been configured as an IJ
module.
GitOrigin-RevId: 47e832edeeea21f5206c981bd604a6012100e9da
This service should be used to execute one-shot processes (when you are only interested in execute-and-get-result).
It also supports simple helpers.
Code is fully Eel-compatible.
See `ExecService` and its showcase as an entry.
GitOrigin-RevId: 38f04914667b9b6c979c3cfe5acdd48718a75229
PythonCore consists of several v1 modules (they aren't v2 modules in its content, but bare v1 modules to be packed directly in it).
They used to have `com.jetbrains` package to match plugin's package.
I now removed plugin package and moved modules to the appropriate packages.
https://jetbrains.slack.com/archives/CMDBCUBGE/p1738073999835749?thread_ts=1738008244.276339&cid=CMDBCUBGE
GitOrigin-RevId: 5702998a23598d4aa363064025afad8951faf7f7
poetry is v1 module, it doesn't go to the plugin content (because plugin depends on it), so building system doesn't have an idea how to include it: we must include it manually
GitOrigin-RevId: f214eafb7bad150c0a25443b0cabfb11b1cebc92
Introduced PackageManagerServiceInterface to standardize package management across services, replacing direct use of PyPackagingToolWindowService with PackageManagerHolder.
GitOrigin-RevId: ff93b45ed0603d4f26d9c698542653d4aa38842e
If a module is compatible with the frontend process (i.e., doesn't depend on 'intellij.platform.backend' module), it's now automatically put to a separate JAR: lib/modules/module.name.jar for content modules, and lib/*-frontend.jar for other modules.
The expected plugin layout is updated for some plugins that we may want to use in the frontend process in the future.
Also, peculiarities of CWM plugin layout are fixed: we don't have two copies of intellij.platform.inline.completion.split and intellij.platform.vcs.common.split modules anymore. The 'package' attribute is removed from backend modules intellij.platform.inline.completion.backend.split and intellij.platform.vcs.backend.split to ensure that they are also put to separate JARs and aren't scrambled, so there is no need to include their dependencies to the scrambling classpath.
GitOrigin-RevId: 05cc64ddff100726a64538000bbde224095adc2c
See `README.txt`.
The "Python Services" is a new API for PyCharm execution subsystem.
The idea is to build the following mental model:
1. If you need an API -- there should be a service.
2. Each service has a showcase in "tests" root so you can see how it works in real life.
3. Code against interfaces.
4. Only link against those modules/services you really need.
5. No UI, no leaky abstractions in services.
This change introduces two services:
1. `SystemPythonService` to work with CPythons installed on OS.
GitOrigin-RevId: b07df246d1510a02c060fa7a929cf134879c7677
Fix build issues
Fix build issues
Remove redundant extension point
Fix build issues
Fix rebase issues
import rank
# Conflicts:
# .idea/libraries/jetbrains_ml_models_python_imports_ranking_model.xml
# .idea/libraries/jetbrains_mlapi_ml_feature_api.xml
# build/expected/ultimate-content-platform.yaml
# community/.idea/libraries/jetbrains_mlapi_ml_building_blocks.xml
# community/.idea/libraries/jetbrains_mlapi_ml_feature_api.xml
# community/platform/ml-api/intellij.platform.ml.iml
# community/platform/ml-impl/intellij.platform.ml.impl.iml
# community/platform/ml-impl/src/com/intellij/platform/ml/impl/logs/fus/IntelliJFusEventRegister.kt
# community/platform/ml-impl/src/com/intellij/platform/ml/impl/logs/fus/eventFields.kt
# community/platform/ml-impl/src/com/intellij/platform/ml/impl/tools/logs/IntelliJFusEventRegister.kt
# community/platform/ml-impl/src/com/intellij/platform/ml/impl/tools/logs/eventFields.kt
# community/platform/ml-tools/src/com/intellij/platform/ml/tools/logs/fus/IntelliJFusEventRegister.kt
# community/platform/ml-tools/src/com/intellij/platform/ml/tools/logs/fus/eventFields.kt
# community/platform/platform-impl/codeinsight-inline/src/com/intellij/codeInsight/inline/completion/ml/TypingSpeedFeatureProvider.kt
# community/python/intellij.python.ml.features/src/com/intellij/python/ml/features/imports/README.md
# community/python/intellij.python.ml.features/src/com/intellij/python/ml/features/imports/mlModel.kt
# community/python/pluginCore/plugin-content.yaml
# community/python/src/com/jetbrains/python/codeInsight/imports/mlapi/mlAnalysis.kt
# community/python/src/com/jetbrains/python/codeInsight/imports/mlapi/mlImplementation.kt
# community/python/src/com/jetbrains/python/codeInsight/imports/mlapi/mlLogs.kt
# community/python/src/com/jetbrains/python/codeInsight/imports/mlapi/mlTask.kt
Fix some tests
Refactor RelevanceEvaluationFeatures.kt to fix null handling
Improved the handling of `null` cases for `MODULE_SOURCE_TYPE` in `RelevanceEvaluationFeatures.kt`. This ensures more robust feature addition by checking conditions and setting the value accordingly when it's `null`. Minor formatting adjustments were also made.
Update ML model version in project configuration
Changed the Maven artifact ID from "lilac-coua" to "daffy-pony" for the python imports ranking ML model.
Fix some tests
Fix some tests
Fix some tests
Fix some tests
Fix some tests
Update Maven dependencies for JetBrains ML libraries
Update ML model version & fix missing read action
Update ML API version & update Imports Ranking implementation
Update mlapi version
Co-authored-by: Andrey Vokin <andrey.vokin@jetbrains.com>
Co-authored-by: Nikita Ermolenko <ermolenko.dev@gmail.com>
Merge-request: IJ-MR-147271
Merged-by: Gleb Marin <Gleb.Marin@jetbrains.com>
GitOrigin-RevId: 7aa520df915bb8a62263524868a17a984b619728
Fix smoke tests
Update ML libraries
Remove kotlin std from classes of a library
Remove redundant extension point
import rank
PY-40997 Typing/Reformatting/Autocomplete lags when stubs for boto3 are installed
set test iteration count to 12
Co-authored-by: Gleb Marin <Gleb.Marin@jetbrains.com>
Merge-request: IJ-MR-150955
Merged-by: Gleb Marin <Gleb.Marin@jetbrains.com>
GitOrigin-RevId: 47140fd0301283a10966e14c65df9a08d128ec39
FUS statistics consists of two parts:
1. Interpreter (i.e "venv" or "conda")
2. Project generator type ("Django" or "Flask")
`com.jetbrains.python.newProjectWizard.collector.PythonNewProjectWizardCollector.GENERATOR_FIELD` was a class without any limitation and `DirectoryProjectGenerator` instance was reported (i.e one for Django).
When migrated to NPW, we:
1. Dropped most old generator classes
2. Called this function providing `this::class` by accident, and it was `CoroutineScope`, so we finished with lots of `CoroutineScope` as generator type in FUS.
We must:
1. Provide old names for project types to preserve statistics.
2. Make it type-safe this time.
We also found that interpreter statistics is nullable for `PySdkCreator` which isn't true: SDK creation statistics is always not null.
So we:
* Introduce interface for project generators that reports "name for the statistics"
* Implement it both for DS and PyCharm by returning class name by default
* Overwrite it for several well-known generators to preserve statistics (use old named of now-deleted classes)
* Make interpreter statistics not null.
GitOrigin-RevId: 37eefb73361ff96dea88e4e2b4c6b291a91e13f0
Associate poetry files ("poetry.lock", "pyproject.toml") with the Python Packages toolwindow.
Separate UI error handling from package management logic.
Add tests to check the installation and removal of packages using poetry and "pyproject.toml" modification.
Merge-request: IJ-MR-146002
Merged-by: Egor Eliseev <Egor.Eliseev@jetbrains.com>
GitOrigin-RevId: 2ab0816f10c970f738d6d931dc123481030cad38
In SDK:
* `v1`: legacy API that should be dropped (but still used by Python Plugin and DS)
* `v2`: slightly better API used both for new project and interpreter settings. Supports DSL UI validation. Must be adopted by DS and Python Plugin somehow.
In NPW:
* `newProject`, `newProject/steps` (aka `v1`) deprecated, used only by DS and Python Plugin.
* `newProjectWizard` (aka PyV3): the right new API to use. Sooner or later will be adopted by DS and Python Plugin
GitOrigin-RevId: c3d49ce95079dc5ba589955381ddfe42326295fd
