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.52
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

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 46 Next › Last »

iamkarlson commented on 2024-04-08 10:55 (UTC)

The latest version crashes sway:

 segfault at 40 ip 000077a6af765c38 sp 00007ffc4d64bd08 error 6 in libwayland-server.so.0.22.0[77a6af763000+8000] likely on CPU 1 (core 0, socket 0)

Xavier commented on 2024-03-29 12:56 (UTC)

Hi @GodofTheFallen, these types of issues should be reported to the Jetbrains bug tracker, unless you believe it is a packaging issue.

GodofTheFallen commented on 2024-03-28 04:34 (UTC)

There is an issue where the JetBrains window will steal the focus, and other windows above the JetBrains window will be passed through by the mouse. Pycharm's own dropdown bars and pop-up menus will also be passed through and cannot be clicked.

Ashark commented on 2024-02-27 13:29 (UTC)

@Xavier Finally! Thanks!

Xavier commented on 2024-02-18 17:58 (UTC)

@freso, that wrong path is dynamic, it depends on where you are building the package, so it is more complicated to just do a sed besides in future updates there could be more files (or not, we don´t know). Of course I prefer not to manipulate the file system outside the package manager, but we don't know the consequences of having wrong paths in the speed-up debugging.

Freso commented on 2024-02-18 17:25 (UTC)

With 4479465010ef2f6a58bc764b613e929daef79a6e (pkgrel=5) I get a hit on /usr/src/debug/pycharm-professional/pycharm-2023.3.3/plugins/python/helpers/pydev which doesn’t exist anywhere on my system.

This feels very similar to “WARNING: Package contains reference to $srcdir” (which I thought was what this was about at first, hence my grep’ing) and while I get that it may not be the neatest to have a "wrong" path in there, I’d argue that it’s way less neat to manipulate the file system outside of the package manager, especially if there is no confirmed issues arising from not doing so. If it turns out there is an issue, it should probably be filed as a bug with upstream. (I guess there’s always the option of sed -i 's|/usr/src/debug/pycharm-professional/pycharm-[0-9.]\+/|/opt/pycharm-professional/| or similar too…)

I’ll try and look into if there’s something that can be passed to build_ext to make it not include these paths, but even if not, I have a working PKGBUILD that doesn’t offend my sensibilities, so whether you choose to adopt any of my changes for that or not, it’ll only be a slight minor annoyance for me come update time if you don’t. :)

Ashark commented on 2024-02-18 13:58 (UTC) (edited on 2024-02-18 13:59 (UTC) by Ashark)

@Xavier Thanks for your thinking of that. Because that is really an inconvenience. For example, I currently switch to this non-eap version, because in eap, the UML diagrams are broken. But still I need the eap version to test some other stuff.

In the listing of package (yay -Ql pycharm-professional) the most files are already in /opt/pycharm-professional.

I only see the following files that may potentially conflict with other packages (not yet checked):

/usr/bin/ltedit - can be renamed as ltedit-pycharm-professional for example
/usr/bin/pycharm - can be renamed as pycharm-professional for example
/usr/share/applications/ltedit.desktop - may be renamed as ltedit-pycharm-professional.desktop for example (does not influence on the actual name in the app menu)
/usr/share/icons/hicolor/128x128/apps/pycharm.png - as pycharm-professional.png and edit in the desktop file (there is no extension there)
/usr/share/icons/hicolor/scalable/apps/pycharm.svg - as pycharm-professional.svg and edit in the desktop file (there is no extension there)

Xavier commented on 2024-02-18 02:06 (UTC)

@Freso run grep -a "/pycharm-professional" /opt/pycharm-professional/plugins/python/helpers/pydev/_pydevd_bundle/pydevd_cython.cpython-311-x86_64-linux-gnu.so however I am not entirely sure that is really affecting the plugin if it shows a wrong path but I prefer avoid that.

Freso commented on 2024-02-18 00:14 (UTC)

1) I’m not reproducing. This is from my pkgrel=5 PKGBUILD:

freso@din ~ (main)> lddtree /opt/pycharm-professional/plugins/python/helpers/pydev/_pydevd_bundle/pydevd_cython.cpython-311-x86_64-linux-gnu.so
/opt/pycharm-professional/plugins/python/helpers/pydev/_pydevd_bundle/pydevd_cython.cpython-311-x86_64-linux-gnu.so (interpreter => None)
    libc.so.6 => /usr/lib/libc.so.6
        ld-linux-x86-64.so.2 => /usr/lib/ld-linux-x86-64.so.2
freso@din ~ (main)> grep -F 'makepkg' /opt/pycharm-professional/plugins/python/helpers/pydev/_pydevd_bundle/pydevd_cython.cpython-311-x86_64-linux-gnu.so
freso@din ~ (main) [1]> grep -F '/usr/lib' /opt/pycharm-professional/plugins/python/helpers/pydev/_pydevd_bundle/pydevd_cython.cpython-311-x86_64-linux-gnu.so
grep: /opt/pycharm-professional/plugins/python/helpers/pydev/_pydevd_bundle/pydevd_cython.cpython-311-x86_64-linux-gnu.so: binary file matches

either way, the current .install files both install files in the file system not managed by the package manager – and I’m not sure if the chroot’ing of post_remove() prevents this, but if not, this might also remove files that might intentionally exist in the file system outside of this package (e.g., if someone made a package to install a PyCharm plugin to /opt/pycharm-professional/plugins/).

2) It’s still an approved RFC, work is happening. It’ll be ready when it’s ready.

3) Part of the point with that commit is that there currently is no actual conflict between those packages, other than them being listed in this package’s $conflicts array. They can happily exist side-by-side as it is, right now, without any changes to any packages (other than cleaning up the $conflicts).

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 46 Next › Last »