Arch Linux User Repository

Does this package makes sense at the time when EAP is closed? I see you package 2024.1.1.241.15989.111, while the regular version is currently (from the download page on their website):

Version: 2024.1.1
Build: 241.15989.155
30 April 2024

So, it is a bit newer than yours.
I suggest to pin the comment with this info.

Thank you!

@Ashark, thanks for the suggestion. It is done.

@qft Can you please change "Name=PyCharm Professional Edition" to "Name=PyCharm Professional Edition (EAP)" to differentiate it from the non-eap edition. I have installed them in parallel, and it is hard to identify the needed app when launching.

Also, probably worth adding a "Keywords=eap".

Pycharm is only official supported for x86 and arm64, so I have made a patch which set supported architectures to x86, arm64 and links to the correct sources

diff --git a/PKGBUILD b/PKGBUILD
index 764214a..85aaacc 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -10,7 +10,7 @@ _eap=false
 pkgver="${_pkgver}.${_buildver}"
 pkgrel=1
 pkgdesc="Powerful Python and Django IDE, Early Access Program (EAP) build. Professional edition."
-arch=("any")
+arch=('x86_64' 'aarch64')
 options=("!strip")
 url="https://www.jetbrains.com/pycharm/nextversion/"
 license=("custom")
@@ -28,15 +28,21 @@ optdepends=('ipython: For enhanced interactive Python shell inside Pycharm'
 provides=("pycharm" "pycharm-professional")

 if [[ $_eap = false ]]; then
-    source=("https://download.jetbrains.com/python/pycharm-professional-${_pkgver}.tar.gz"
-    "${pkgname}.desktop")
+    source_x86_64=("https://download.jetbrains.com/python/pycharm-professional-${_pkgver}.tar.gz")
+    source_aarch64=("https://download.jetbrains.com/python/pycharm-professional-${_pkgver}-aarch64.tar.gz")
 else
-    source=("https://download.jetbrains.com/python/pycharm-professional-${_buildver}.tar.gz"
-    "${pkgname}.desktop")
+    source_x86_64=("https://download.jetbrains.com/python/pycharm-professional-${_buildver}.tar.gz")
+    source_aarch64=("https://download.jetbrains.com/python/pycharm-professional-${_buildver}-aarch64.tar.gz")
 fi
+sha256sums_x86_64=(
+    "add6cb45aed969a49b21322fbd2e34c896f2a618d2a9eb8c865a05602365ef6c"
+)
+sha256sums_aarch64=(
+    "c910983a2d23d32265335cb5cb96b7d853879379cc0f8510ba690419afee1238"
+)

-sha256sums=("add6cb45aed969a49b21322fbd2e34c896f2a618d2a9eb8c865a05602365ef6c"
-            "7801ea1379c4c183efeb78ec8d2f67bc30741548410fa51b9f4827b0188da4b2")
+source=("${pkgname}.desktop")
+sha256sums=("7801ea1379c4c183efeb78ec8d2f67bc30741548410fa51b9f4827b0188da4b2")

 prepare() {
     if [[ -d $srcdir/pycharm-${_pkgver} ]]; then

PyCharm EAP without extra qualification is synonymous with the Professional version, as per JetBrains’s own usage. And JetBrains does not even provide a download webpage for the Community version. Since the Professional version is the default, there is no need to qualify the name, and only the non-default version needs to be qualified. This is analogous to how Python packages were handled before Python 2's EOL. Before the EOL, the Python 3 package was simply referred to as 'python', while the older version was qualified as 'python2' to distinguish it as the non-default version.

name has been used since 2011. I don't think changing the name of such long-established package is a good idea unless there's compelling benefit.

I disagree with this statement. The package naming should be consistent. Distributions sometimes change the packages name as needed.

It would require users to adapt to a new naming convention for a package that essentially remains the same, introducing unnecessary complications.

Just a simple example, all KDE packages were renamed to the packages with "5" a the end, when the plasma 6 beta appeared. For example, analitza -> analitza5.

A change in the package name after over a decade could disrupt automated scripts, dependencies, and user familiarity.

What are you about exactly? The automated scripts that build the aur package? Even there is no any dependent package.
Regarding the thing that you want this to remain searchable for those who search "pycharm-eap", you can add it to the "replaces" array (not to the "provides"). See https://wiki.archlinux.org/title/PKGBUILD.

This nomenclature suggests that the EAP version inherently pertains to the Professional edition

This is not obvious. This is also a reason why I suggest the rename.

making the addition of 'professional' in the package name redundant.

Actually, this oppositely made me unsure about this package when I was selecting the package to install. And we need to differentiate with pycharm-community-eap, and also for consistency.

Yeah, I see you added "Professional Edition" to the description, but really, please rename also the package. The history and the comments will remain (you just submit a merge request).

@Ashark this package name has been used since 2011. I don't think changing the name of such long-established package is a good idea unless there's compelling benefit. A change in the package name after over a decade could disrupt automated scripts, dependencies, and user familiarity. It would require users to adapt to a new naming convention for a package that essentially remains the same, introducing unnecessary complications.

Like I mentioned before, JetBrains uniformly refers to PyCharm EAP without specifying 'Professional' anywhere on their official website. This nomenclature suggests that the EAP version inherently pertains to the Professional edition, making the addition of 'professional' in the package name redundant.

Why this packagebase does not provide a jre package?

@qft Thanks for maintaining. Can you please rename the package as "pycharm-professional-eap", to indicate that this package edition - to keep it consistent with other aur packages and to differ from pycharm-community-eap in aur.