Package Details: pycharm-professional 2024.3.5-1

Git Clone URL: https://aur.archlinux.org/pycharm-professional.git (read-only, click to copy)
Package Base: pycharm-professional
Description: Python IDE for Professional Developers. Professional Edition
Upstream URL: https://www.jetbrains.com/pycharm/
Keywords: development editor ide jetbrains python
Licenses: custom
Submitter: hippojazz
Maintainer: Xavier (37h4n)
Last Packager: Xavier
Votes: 292
Popularity: 0.49
First Submitted: 2013-09-25 03:56 (UTC)
Last Updated: 2025-03-20 13:26 (UTC)

Dependencies (19)

Required by (0)

Sources (4)

Pinned Comments

Latest Comments

1 2 3 4 5 6 .. 46 Next › Last »

Xavier commented on 2025-03-29 01:44 (UTC)

@tilx, read these instructions on https://aur.archlinux.org/packages/pycharm-professional#comment-1002854 about manual intervention after update v2024.3.1.1

tilx commented on 2025-03-28 09:28 (UTC) (edited on 2025-03-28 09:31 (UTC) by tilx)

I got an error upgrading PyCharm:

error: failed to commit transaction (conflicting files)
pycharm-professional: /opt/pycharm-professional/plugins/python-ce/helpers/pydev/pydevd_attach_to_process/attach_linux_amd64.so exists in filesystem

Renaming the existing file let me complete the upgrade.

There is only a small difference between the binaries:

$ cmp -l /opt/pycharm-professional/plugins/python-ce/helpers/pydev/pydevd_attach_to_process/attach_linux_amd64.so{,.old}
  745 224 204
  746 267 214
  747 216 345
  748  66 312
  749 275 244
  750  31 316
  751 151 163
  752  51 342
  753 312  33
  754  16 266
  755 153  15
  756  77 355
  757 173 176
  758 366 326
  759 143 240
  760 132  76
  761 140  60
  762 176 273
  763   2 367
  764 253 333
24878  65  64
24880  62  71
24881  60  61
24882  67  60

hornobster commented on 2025-02-08 16:55 (UTC) (edited on 2025-02-08 17:45 (UTC) by hornobster)

@Xavier I still can't get it to work.

I have downloaded the package source with yay -G pycharm-professional, built the package with makepkg without touching the PKGBUILD first, and then retried after deleting both prepare() and build() from PKBUILD.

For now I am running all debug sessions with PYDEVD_USE_CYTHON=NO;PYDEVD_USE_FRAME_EVAL=NO as env variables.

EDIT: I think the problem is that the Cython extension is compiled for the system python, python 3.13, while I'm trying to debug a script in a venv for python 3.12. I don't know if there is a proper way of doing this.

EDIT 2: That was the problem. In PKGBUILD build() I have added a second extension compilation like so:

    # compile PyDev debugger used by PyCharm to speedup debugging
    python ./plugins/python-ce/helpers/pydev/setup_cython.py build_ext --inplace --force-cython
    /home/user/.pyenv/versions/3.12.8/bin/python ./plugins/python-ce/helpers/pydev/setup_cython.py build_ext --inplace --force-cython

I don't know if it would make sense to automatically build the extension for each installed pyenv python version in the PKGBUILD.

unbis commented on 2025-02-06 14:17 (UTC)

I just also encountered a speed-up build error 

  File "/tmp/pycharm-professional/src/pycharm-2024.3.2/./plugins/python-ce/helpers/pydev/setup_cython.py", line 111, in build_extension
    from Cython.Build import cythonize
ModuleNotFoundError: No module named 'Cython'

took me a while to figure out that I still had the legacy cython0 installed. Using the normal cython instead solved the issue for me. (Thought I'd share this and save somebody else the debugging time.)

Xavier commented on 2025-02-06 12:52 (UTC)

@hornobster, yes the error could be because your PYenv, try to download the source with yay -G and build it manually makepkg in a clean shell. If the problem persists, delete the section prepare() and build() in the pkgbuild file

hornobster commented on 2025-02-06 11:28 (UTC)

I can't make it work. I have reinstalled again in a clean shell with yay pycharm-professional --overwrite '/opt/pycharm-professional/plugins/python-ce/helpers/pydev/*', but nothing changed.

Could it be related to my use of pyenv? PYenv isn't active when installing pycharm, but I use it for my projects (e.g. for python 3.12 venv) and when trying to debug.

Xavier commented on 2025-02-03 20:22 (UTC)

Hi @hornobster, it seems like you have some issues with the Cython Speed ​​Up, try to build the package in a clean shell (or clean chroot) maybe you have some rust, python or other configuration in your environment. When you are building the package check the logs for errors.

hornobster commented on 2025-02-03 15:33 (UTC) (edited on 2025-02-03 15:34 (UTC) by hornobster)

I am getting the following error when trying to debug any python script:

Traceback (most recent call last):
  File "/opt/pycharm-professional/plugins/python-ce/helpers/pydev/pydevd.py", line 59, in <module>
    from _pydevd_bundle.pydevd_trace_dispatch import (
ImportError: cannot import name 'trace_dispatch' from '_pydevd_bundle.pydevd_trace_dispatch' (/opt/pycharm-professional/plugins/python-ce/helpers/pydev/_pydevd_bundle/pydevd_trace_dispatch.py)

I have tried [aur helper] pycharm-professional --overwrite '/opt/pycharm-professional/plugins/python-ce/helpers/pydev/*', but it didn't work.

Disabling the cython optimisations debugging works.

Xavier commented on 2024-12-23 14:52 (UTC)

@0xc0ffee, I decided to change it because it was not only due to what you mentioned; other people also reported some problems with the post-script build. Originally, I included it in the post-script for reasons related to what you mentioned (specifically regarding the paths, which is why you can see a warning during the pkgbuild process). However, I believe this is not an issue, and they work well. These are binaries, and they are linked more to the Python/Cython versions than to the paths, unless someone reports or detects an issue related to this.

0xc0ffee commented on 2024-12-22 10:17 (UTC) (edited on 2024-12-22 12:00 (UTC) by 0xc0ffee)

@Xavier Thanks for the update.

Maybe I didn't express my idea clearly, but my point is that I'm pretty sure the error message that supply730 and I saw is a false alarm and it is benign. If you don't use pamac as your frontend for libalpm, you will not encounter that false alarm. I think the ideal fix here would be to submit a PR to Manjaro's pamac with better error detection logic.

JetBrains supplies pre-built Cython modules only for macOS and Windows, not for Linux. I am against the idea of lifting the Cython speedups job to packaging time. I know that in many cases the machine building this AUR package will also be the machine using it, but do we really want to make such an assumption? If there is any Python environment discrepancy between the packaging machine and the using machine, I'm worried those Cython modules may not work reliably. I believe this is one of the reasons why JetBrains wants Linux users to build those modules themselves.

1 2 3 4 5 6 .. 46 Next › Last »