This MR cherry picks changes done for PY-87723 and PY-87578
Merge-request: IJ-MR-193482
Merged-by: David Lysenko <david.lysenko@jetbrains.com>
GitOrigin-RevId: c74229ed48ae8702667dda201613a2d0c3f25369
[pycharm] PY-87123 Synchronize build files
[pycharm] PY-87123 Add icons for process weight
[pycharm] PY-87123 Extract Pipenv icons/mapper into a pipenv module
[pycharm] PY-87123 Extract Conda icons/mapper into a separate module
[pycharm] PY-87459 Fix process tree autoscroll
Fixes an issue in which the process tree would not automatically scroll up
after new processes are added.
[pycharm] PY-87112 Change the icon of the tool window to a new one
[pycharm] PY-87123 Rename `Styling` object to `OutputSectionStyling`
This is done to match the naming of `TreeSectionStyling`.
[pycharm] PY-87123 Render spinner instead of an icon for running processes
[pycharm] PY-87123 Refactor TreeSection
* Extract tree content into its own composable
* Extract styling values into a styling object
* Remove redundant icons that can be constructed programmatically
[pycharm] PY-87123 Address feedback
[pycharm] PY-87123 Implement custom styling for critical errors
Critical errors are ones that are displayed to the user via the error sink.
[pycharm] PY-87123 Add tool-dependant icons to POTW process tree
[pycharm] PY-87123 Implement ProcessOutputIconMapping extension point
The extension point provides a way for tooling-related modules to define
custom mapping between file extensions and icons that should be used by
the Process Output Tool Window.
Merge-request: IJ-MR-189367
Merged-by: David Lysenko <david.lysenko@jetbrains.com>
GitOrigin-RevId: 0d728779f04f2066e929954681ec7a23741f5f74
Non-project files by default are not indexed, do not have a module and do not have an SDK.
`PyExternalFilesIndexService` is resposible for adding a custom entities to the workspace model.
Space-RevId: dd7c50009e56dea0d69914c9f7f1524c7e77fe20
GitOrigin-RevId: cdfa2a578a01431fb9e0a06ce820c1d9b0f3fc0d
IdeaUltimatePluginModuleDependenciesTest failed with the following message: `Plugin 'Python Community Edition' conflicts with 'IDEA CORE' and may work incorrectly. Their respective modules 'intellij.platform.ide.nonModalWelcomeScreen' and 'intellij.platform.ide.nonModalWelcomeScreen' declare the same package prefix`
GitOrigin-RevId: af33d6b2f341b90103a7db1e0ff5b5a3131427d9
Each tool (uv, poetry) now has `common` and `backend` part. `common` has icons because we need them both on the front and on the back.
We might need to create `front` module also if we wouldn't be able to use icons in compose.
GitOrigin-RevId: b5662fbdf3d23f1ddaa5926469d1cfd2051a0fba
We are slowly moving all tools to the separate modules to register them as EP. On the front we might have `ToolId` only. To map it to an icon we will use EP.
GitOrigin-RevId: 642f4b8d77a0a14b6b61a5192607fbc7984529c7
Before the changes, there wasn't any mechanism to detect that
environment was already created (for example, .venv exists in the
project). In these situations, during SDK creation we could've created
another environment which was not expected by users.
With these changes, it's now possible to detect in the configurator that
environment already exists, and use it when creating SDK.
Merge-request: IJ-MR-177317
Merged-by: Alexey Katsman <alexey.katsman@jetbrains.com>
GitOrigin-RevId: a612a1069ca5275bedbcfa6af9377059dab7c072
It should be named `intellij.python.frontend`, but this name is occupied by another module, that should be named `intellij.python.frontend.split`
GitOrigin-RevId: 9c691512950b1f02cebd4a2d201560650460b16c
This module listens for topic that model was just rebuilt from `pyproject.toml` and does its best to configure SDK.
It will support UI to make this process configurable
GitOrigin-RevId: c752c94385814b5fc4413316c0d9d4cc2adb41e4
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
