Package Details: pycharm-eap 2024.1.241.14494.241-1

Git Clone URL: https://aur.archlinux.org/pycharm-eap.git (read-only, click to copy)
Package Base: pycharm-eap
Description: Powerful Python and Django IDE, Early Access Program (EAP) build. Professional edition.
Upstream URL: https://www.jetbrains.com/pycharm/nextversion/
Keywords: development editor ide jetbrains python
Licenses: custom
Provides: pycharm, pycharm-professional
Submitter: vlan
Maintainer: qft
Last Packager: qft
Votes: 31
Popularity: 0.002798
First Submitted: 2011-05-06 08:33 (UTC)
Last Updated: 2024-04-05 23:07 (UTC)

Dependencies (12)

Required by (0)

Sources (2)

Latest Comments

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

Ashark commented on 2024-04-05 23:10 (UTC)

Thank you!

qft commented on 2024-04-05 23:08 (UTC)

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

Ashark commented on 2024-04-05 17:11 (UTC)

@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".

muhaha commented on 2023-12-29 00:04 (UTC)

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

qft commented on 2023-12-21 20:58 (UTC) (edited on 2023-12-21 21:08 (UTC) by qft)

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.

Ashark commented on 2023-12-21 19:25 (UTC)

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

qft commented on 2023-12-21 18:31 (UTC)

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

Ashark commented on 2023-12-15 10:39 (UTC)

Why this packagebase does not provide a jre package?

Ashark commented on 2023-12-13 20:47 (UTC)

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