Such modules can be referenced not by a 'dependencies.module' tag, but via a 'depends' or 'dependencies.plugin' tag with the plugin alias, so they should be public. 'jetbrains' namespace is used for them.
GitOrigin-RevId: f3d0601685fe1d312a2508be08e97f8d985e7133
This service is aimed to substitute various SDK-management tools in PyCharm.
Begin with `InterpreterService()` function.
GitOrigin-RevId: 368d56c4a78812fe81de941e5e5ce61a56d385e6
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
* 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
Whenever a pyproject.toml file is found in a new IJ project root
(without .idea) we register the corresponding root as managed by Poetry
in `.idea/poetry.xml` (so called "linking") and then read all
pyproject.toml in the project tree setting up the corresponding IJ
modules and dependencies between them (so called "syncing").
The changes are persisted in the workspace model cache, there are
no additional config files, besides `.idea/poetry.xml`.
If a new pyproject.xml module is added to the root of an existing
project, we ask user whether its project model should be applied.
When a pyproject.toml is then changed in the editor or externally,
we either automatically apply the changes (reloading) or ask
a user about it, depending on the settings in
"Settings | Build, Execution, Deployment | Build Tools".
If automatic linking and syncing doesn't work for some reason
(e.g. there is no top-level pyproject.toml as in grazie-ml),
there are manual actions "Link All Poetry Projects" and
"Sync All Poetry Projects".
GitOrigin-RevId: 77a480cdf56d45f22c943acbad3a7c20d5eb56a5
1. Preload pythons from a project start activity
2. Cache them for some time (see `cache` variable)
3. Provide API to refresh
Merge-request: IJ-MR-158389
Merged-by: Ilya Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: 8b58ad3f35f144364d4103578d20a3cfc9b637f2
* use module sdk instead of project sdk in dependency completion
* remove dependency on the "requirements.txt" in the UnsatisfiedRequirementInspection (might be also pyproject.toml)
* move poetry-related things to own package
GitOrigin-RevId: 878ad4c419ed8025aa27bca2357ec7bed2e26f3c
* add new / select existing for local sdks
* create a new project with hatch sdk
* open hatch-managed project
GitOrigin-RevId: 86e970a39bc44cec34be7c82717806fc4d0009c4
* Move Python-specific file types up in the "NewGroup" actions group
* Rename several actions so that their naming is aligned with the corresponding actions' names in IntelliJ platform
GitOrigin-RevId: af828c30daa801c0ca52c1271be45279946e34f0
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
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
Introduced PackageManagerServiceInterface to standardize package management across services, replacing direct use of PyPackagingToolWindowService with PackageManagerHolder.
GitOrigin-RevId: ff93b45ed0603d4f26d9c698542653d4aa38842e
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
