Package Details: pycharm-professional 2024.3.2-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: 293
Popularity: 1.73
First Submitted: 2013-09-25 03:56 (UTC)
Last Updated: 2025-01-28 12:53 (UTC)

Dependencies (19)

Required by (0)

Sources (4)

Pinned Comments

Xavier commented on 2024-12-20 15:15 (UTC)

MANUAL INTERVENTION FOR v2024.3.1.1:

Due to the latest changes for the cython speed up, this release is going to show a commit transaction conflicting files, to fix this you need to enable Cython Speed ​​Up file overwriting:

[aur helper] pycharm-professional --overwrite '/opt/pycharm-professional/plugins/python-ce/helpers/pydev/*'

or after manual build:

sudo pacman -U pycharm-professional-2024.3.1.1-1-x86_64.pkg.tar.zst --overwrite '/opt/pycharm-professional/plugins/python-ce/helpers/pydev/*'

Latest Comments

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

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

Xavier commented on 2024-02-17 23:51 (UTC)

@Freso thanks so much for your contributions, 1) Of course, before I had the compilation of the speed-up debugging inside the PKGBUILD as you propose, the problem with that it generates wrong paths linked inside the .so files check this comment. 2) interesting about the x86_64_v3 but the discussion is very old, is it going to happen?. 3) I'm going to fix this kind of conflict when I resolve the problem of conflict with other pycharm package that we have been discussing with @ashark

Freso commented on 2024-02-17 23:36 (UTC)

(Relatedly, as far as I can discern, https://gitlab.archlinux.org/freso/pycharm-professional/-/commit/4479465010ef2f6a58bc764b613e929daef79a6e should be enough to allow Ashark to run this with their pycharm-eap build without you renaming /usr/bin/pycharm (and Ashark could also choose to just do this edit to their local PKGBUILD before makepkg’ing it).)

Xavier commented on 2024-02-17 23:20 (UTC)

@ashark ok sounds reasonable, I'm going to do that but first I need to check if exists another conflict, I guess it is only the executable.

Freso commented on 2024-02-17 20:00 (UTC) (edited on 2024-02-17 20:15 (UTC) by Freso)

Hi! I cloned this package to move the compilation currently happening in the .install files into the PKGBUILD itself: https://gitlab.archlinux.org/freso/pycharm-professional/-/commits/no-install-file

While I was at it, I also included support for the Coming Soon™ "x86_64_v3" $CARCH: https://gitlab.archlinux.org/freso/pycharm-professional/-/commits/x86-64-v3

Since these are all in git, you should be able to merge/rebase/cherry-pick the commits into the AUR git repository if they should be desired. :)

Edit: Also did one more commit to clean up the $conflicts array a bit: https://gitlab.archlinux.org/freso/pycharm-professional/-/commits/clean-conflicts

Ashark commented on 2024-02-12 06:35 (UTC)

@Xavier This is not a problem. That file "/usr/bin/pycharm" is just a convenience symlink. You are not changing the name of executable, which is resided in the "/opt/pycharm-professional/bin/pycharm.sh". Just change it to "pycharm-pro" for example.
The official installer does not make a symlink. Instead, in the desktop file in Exec they write the path to the file in /opt.

It is expected functionality to be able to install several IDEs side by side. With this not fixed, I need to constantly remore/reinstall the package of other version... to be able to install this package.

Xavier commented on 2024-02-12 01:43 (UTC)

@ashark, to do that we need to change the executable name, my concerns about that are mainly two: First, not obeying the Archilinux guidelines/philosophy of following upstream closely, reducing the need for local modifications. Second, users impact by changing the executable name, mostly for those who use the cli. So I'm not entirely sure about doing it for now...

Ashark commented on 2024-02-11 19:14 (UTC)

@Xavier @37h4n This package still conflicts with pycharm-community-edition and pycharm-eap. Please fix this.

BlurryFlurry commented on 2023-12-25 03:49 (UTC)

@Xavier, by changing to the bundled JRE, fixed the issue. thank you for heads up