Now we have Code Vision hints which determine the author via Git history and show it in the editor automatically, and this information is more accurate than the tags which were automatically added when files were created.
GitOrigin-RevId: f1b80125c2555d89f32aae4e5290d7771a357abf
Using `Sdk.getHomePath()` as the path to interpreter is not reliable for every case. For example, for legacy remote interpreters `Sdk.getHomePath()` contains prefix, which is used to distinguish different types of remote credentials (for example `sftp://` or `docker://`). It also contains the representation of the value of the remote credentials used. In this case the interpreter path is available via `PythonSdkAdditionalData.getInterpreterPath()`.
These changes fix the problem introduced in c63b57aac9b5a267b3a6710902670bfe7d10c722.
GitOrigin-RevId: a7dc2579d1b0b367353fbecf4b9fe4a56b098e9b
See last comment in PY-57226.
* Use console encoding for PythonExecution
* DO NOT provide ``PYTHONIOENCODING``
* Build PyCharm without of ``file.encoding``
Merge-request: IJ-MR-98463
Merged-by: Ilya Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: 943402d55d3c4aa5460b2fae2602ed43e88029ce
See ``TargetedCommandLineBuilder.addEnvVars`` doc for the main issue.
We also add fix to patch path in PythonScripts
GitOrigin-RevId: f42044338f91d5b444c5e1431957272392ab5f1c
What was wrong:
For SDK creation we execute python to get python path for homePath (see ``PyAddCondaTools``).
So, we execute python on conda before homePath set.
On each execution we read vars from ``activate.bat`` to workaround conda SSL in path problem and activate terminal (since cmd in terminal still uses old API).
``PySdkUtil`` can't read vars when homePath not set, hence caches empty vars for SDK and both terminal and conda workaround stop working until IDE restart.
We now stopped caching empty vars if homePath is empty.
GitOrigin-RevId: de3e37bbbc5281775e3fca79840089561ceed189
This is a quick-and-dirty for terminals. Regular conda execution shouldn't be affected since we store python path in ``homePath`` now.
With this change, ``activate.bat`` read by IJ and vars (including ``PATH``) are passed to the terminal
GitOrigin-RevId: 711e5ea84519894ad3779626d4411196abb5a6b6
``PYCHARM_HOSTED`` makes ``Coloroma`` assume that ``isatty() == true`` (even for bat file redirected to another file) which leads to problems on Windows. See issue comments for more info
GitOrigin-RevId: b82b25e7175330ae86604fc14012ef85e2b8ba0b
Each sdk has additional data with flavor and flavor-specific data. For target-based SDK there is also target information. ``PySdkExt`` has extension method that uses this data to execute code on some SDK. For Conda we store path to conda binary and env name.
GitOrigin-RevId: c63b57aac9b5a267b3a6710902670bfe7d10c722
The problem is ``sys.stdout.encoding``.
On Unix Python uses ``LC_`` which is UTF-8 since late 2000s.
But on Windows for non-console based executions (with stdout redirected) it uses one byte encoding (aka non-unicode programs charset) due to backward compatibility with 9x/me.
With one-byte charset you can't have both latin-1 and cyrillic characters.
To fix that, we provide ``PYTHONIOENCODING`` which sets charset explicitly
GitOrigin-RevId: 5c3304e002d80fb5780f11f05fe5f4d1b6aef3ad
``homePath`` isn't unique for things like conda and remote interpreter.
Merge-request: IJ-MR-95540
Merged-by: Ilya Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: 2695cd29f2e102e48e22d751d8fb37a5aea567e4
If "python.use.targets.api" registry flag is disabled:
- display target-based interpreters as invalid;
- show an error on an attempts to run or debug Python run configuration with an assigned target-based Python interpreter;
- show an error on trying to open Python console with a target-based Python interpreter;
- show a warning on an attempt to generate skeletons for target-based interpreters;
- show an empty list of packages for target-based Python interpreters.
GitOrigin-RevId: 97ee828ab289e5104f0539c9ab49e6fab99fe56b
DS-1661 New opened terminal sessions use the Workspace environment even though the opened folder has a different environment set in settings
GitOrigin-RevId: 286d7d076429f6b429b8b5378229d1336a6bca06
DS-1661 New opened terminal sessions use the Workspace environment even though the opened folder has a different environment set in settings
GitOrigin-RevId: e47df9bc9b6ee65e85f0667f0390be7edce4a891
- fix absence of package name if installation failed via file-level warning on requirements file
- get rid of unnecessary columns
- make the dialog resizable
- add forgotten dot to the troubleshooting tip#1
- add paddings to output and command text areas
- move hardcoded strings to bundles
IJ-CR-16145
GitOrigin-RevId: 6bafccd46dc6eb01db31d33d8979cca9c2b99c20
It causes some weird problems with escaping, when in some places the platform
escapes `C:\foo bar\` as `"C:\foo bar\\"` and as `"C:\foo bar"\` in others
(compare ParametersListUtil.escape and CommandLineUtil.backslashEscapeQuotes).
One way or another, Python interpreter gets the path to the skeletons directory
as two separate command line arguments. The platform escaping problem needs
further investigation, but removing the trailing backslashes is the simplest
workaround on the Python plugin side. We stripped them in generator3 anyway.
GitOrigin-RevId: 52c0c1d3733cc004c1f0c2f1bf8cc186dfa698de
PyTransferredSdkRootsKt#transferRoots and PyTransferredSdkRootsKt#removeTransferredRoots skip sdks that are not equal to module one (editable as well).
That's why roots changes were not applied in PythonSdkUpdater#updateSdkPaths but paths to transfer were successfully set.
When PythonSdkUpdater#updateSdkPaths was executed for original sdk, roots changes were not applied since there were no changes in paths to transfer (they were shared with editable copy).
Update PythonSdkAdditionalData containers usages: they returned cached values in `getPathsAsVirtualFiles` after `killAll` was called.
IJ-CR-10935
GitOrigin-RevId: 72a99f7b14e4d30c5886accb0db56d463890f265
It speeds up virtual environment creation (PY-41172), although from now on the latest releases of packaging tools will be installed in the created virtual environment after the 28 days period that should guarantee we are not pulling in automatically releases that have known bugs within (https://virtualenv.pypa.io/en/latest/user_guide.html#wheels)
IJ-CR-9549
GitOrigin-RevId: 563409e9f7ef1d61572989555f572b06b19ded85
