* Switched to the project-level dependency everywhere
* Introduced a new module intellij.platform.ml.logs to separate ml-api library usages from intellij.platform.ml and intellij.platform.ml.impl modules
* The following models has been adapted to the latest ML API version: python imports ranking, fuzzy resolve, completion trigger model, jetenry inline prompt detection, jetenry fleet code classification
Merge-request: IJ-MR-166415
Merged-by: Vladimir Fedorov <890readrid@gmail.com>
(cherry picked from commit 9056efba5a5397a700daabb453ee1477cfaabdf3)
GitOrigin-RevId: 7cfc63d35b55ac968d5a3b789d2ed5f29d4f12d6
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
Replaced the previous "coral-panda" version with "nebulous-albatross" across library configurations.
GitOrigin-RevId: b27b5ad6d2a2f797350f321e3312e2768c068040
* 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
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.
GitOrigin-RevId: ef5561233dee5c13b7ad304bfa0fd5399d30eafd
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
