Package Details: pycharm-professional 2020.1.1-1

Git Clone URL: (read-only, click to copy)
Package Base: pycharm-professional
Description: Python IDE for Professional Developers. Professional Edition
Upstream URL:
Keywords: development editor ide jetbrains python
Licenses: custom
Conflicts: pycharm, pycharm-community-edition
Provides: pycharm
Submitter: hippojazz
Maintainer: XavierCLL
Last Packager: XavierCLL
Votes: 229
Popularity: 4.87
First Submitted: 2013-09-25 03:56
Last Updated: 2020-05-07 16:59

Dependencies (26)

Required by (0)

Sources (5)

Latest Comments

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

nicoulaj commented on 2019-05-26 17:11

The package could have an optdepends on python-docutils-stubs, pycharm asks for it when using sphynx.

XavierCLL commented on 2019-05-08 15:58

The problem with HiDPI displays was fixed with this release 2019.1.2

Dreyk commented on 2019-04-09 09:18

Thank you for coming back PyCharm with JBR!

XavierCLL commented on 2019-04-03 21:22

If someone wants to use the Java of the system (no JBR) using this package, is easy after install run sudo rm -rf /opt/pycharm-professional/jre64

XavierCLL commented on 2019-04-03 20:59

@ilinojkovic check if the old package is in /var/cache/pacman/pkg/, else you need to build manually with makepkg, if you need more help use the wikis or forums.

ilinojkovic commented on 2019-04-03 19:42

@XavierCLL Thanks for the response! I changed the settings as instructed, but I'm not quite satisfied with the results. What is the smoothest way to downgrade to 2018.3.5? Preferably using pacman/yay (arch newbie here btw)

XavierCLL commented on 2019-04-03 18:36

Thanks for your comments guys, @wizpig64 I consider that pycharm-professional must use the JBR, due that JetBrains apply several patches to the original JDK then I don't think necessary have another package like *-native-java (but it is open if you want), I changed it temporally to no-JBR for fix some problems, but I'm seeing that no-JBR come with other problems, I'm sorry for the inconveniences.

I expect that the issues relate with HiPDI will fix soon (not for the 2019.1.1) JetBrains are aware of it [1]

In the correct order to update this package, I should not update to 2019 until JetBrain fix the issues with HiPDI, but considering that this affected few people and being democratic, I just updated it to 2019.1.1 with JBR.

In HiPDI displays (not in all case) is possible to correctly adjust using -Dide.ui.scale=xx and font size in the IDE. @ilinojkovic for that read [2]

[1] [2]

ilinojkovic commented on 2019-04-03 16:33

@XavierCLL can you please be more elaborate what is needed for HiDPI displays? I'm running Manjaro KDE, and from this version of pycharm, forced font dpi from the system does not seem to be used, thus making everything so tiny...

davidism commented on 2019-04-03 15:57

I flagged this package out of date with the mistaken comment that 2019.1.1 fixes the RST issue when using the system JDK. That's not correct, but you can still get the bundled JDK while using the AUR package, there's a plugin that lets you manage it within PyCharm. Official instructions:

wizpig64 commented on 2019-04-03 07:20

For anyone trying to fix PyCharm opening RST files, switch the preview panel renderer from JavaFX to Swing in Settings > Languages & Frameworks > ReStructured Text.

Source: David @

It looks like the JavaFX renderer was broken when this package switched off the bundled Java runtime onto the native system one. This is a repeat of another bug in 2017, something about font subpixel rendering 8 pages back. Eventually the repo switched back to bundled, and I no longer had to edit the PKGBUILD with every update. Now a bug appears, the switch is made again, and more bugs appear.

Switching to native Java in order to fix bugs seems to have a history of creating more bugs. Not to mention creating the work of having to manually edit PKGBUILDs!

@XavierCLL, what do you think of the idea of using two packages for this scenario? Something like pycharm-professional and pycharm-professional-native-java. Then if a user encounters a bug (like hidpi), they can find a pinned comment here saying to switch to the other branch?

From a user experience point of view, having the switch be made for us is destructive, and fiddling with PKGBUILDs and checksums is no fun when we'd rather be developing. I think it makes more sense for the AUR repo to have single opinion on the matter of its dependencies, especially when there are real tradeoffs between the versions. An alternate opinion belongs in another repo with provides: pycharm.

Thank you for spending your time maintaining this repo for the community!