Search Criteria
Package Details: pycharm-eap 251.25410.24_2025.1.1-1
Package Actions
| 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: | 32 |
| Popularity: | 0.001427 |
| First Submitted: | 2011-05-06 08:33 (UTC) |
| Last Updated: | 2025-04-27 16:42 (UTC) |
Dependencies (12)
- cython (cython-gitAUR) (make)
- python-setuptools (make)
- docker-compose (docker-compose-v1-binAUR, docker-compose-gitAUR, docker-desktopAUR) (optional) – For support docker inside Pycharm
- docker-machine (docker-machine-gitlab-binAUR) (optional) – For support docker inside Pycharm
- ipython (ipython-gitAUR) (optional) – For enhanced interactive Python shell inside Pycharm
- jupyter-notebook (optional) – For support Jupyter Notebook
- openssh (openssh-gitAUR, openssh-dnatAUR, openssh-gssapiAUR, openssh-hpn-shimAUR, openssh-selinuxAUR) (optional) – For deployment and remote connections
- python-coverage (optional) – For support code coverage measurement for Python
- python-pytest (optional) – For support testing inside Pycharm with Python
- python-setuptools (optional) – Packages manager for Python, for project interpreter
- python-tox (optional) – Python environments for testing tool with Python
- vagrantAUR (vagrant-gitAUR) (optional) – For support virtualized development environments
Latest Comments
1 2 3 4 5 6 .. 21 Next › Last »
Ashark commented on 2025-04-21 19:52 (UTC)
@qft I suggest removing "pycharm-professional" from "provides", because there is no more separation between professional and community editions.
Ashark commented on 2025-04-21 19:44 (UTC)
@navarroaxel No, it makes lots of sense. See previous comments.
TLDR is that it allows the compare algorithm of pacman to never fail (considering the jetbrains scheme of naming downloaded archives), and also very understandable by human.
If in the version "251.23774.444_2025.1-1" you are complaining about "_2025.1" part, this is opionated, but I think this still is useful.
navarroaxel commented on 2025-04-21 18:51 (UTC) (edited on 2025-04-21 18:52 (UTC) by navarroaxel)
Hi! the version of this package doesn't make any sense. check webstorm-eap (e.g. 251.23774.424-1) or rustrover-eap (e.g. 2025.1pre+251.23774.316-1) as useful alternatives. Thanks!.
RubenKelevra commented on 2024-12-14 06:53 (UTC) (edited on 2024-12-14 06:59 (UTC) by RubenKelevra)
Hey @qft / @Ashark!
To handle versioning changes correctly, you’ll want to increase the epoch by one. Here's how you can do it:
Setting the epoch to
1ensures that version checks prioritize the new scheme. This way, even if the older version number (e.g.,2024.3.243.18137.19-1) looks "larger" than the newer one (243.22562.180_2024.3.1-1), updates will still work as expected.Why is this important? Well, without the epoch bump, users who already installed the package before the versioning scheme change wouldn’t get updates automatically. This happens because
2024is interpreted as "greater" than243. By adding an epoch, you force the update and avoid any confusion.Ashark commented on 2024-12-03 08:35 (UTC) (edited on 2024-12-03 08:40 (UTC) by Ashark)
Oh, wow. The current version is 243.22562.23, while their currently released version is 243.21565.199. How is that possible?
I guess, it appeared in https://www.jetbrains.com/updates/updates.xml, and then they closed EAP program, and then updates.xml stopped listing that 243.22562.23 build.
I am thinking how correct it is to then list the 243.22562.23 as a current eap (as it is delisted).
Ashark commented on 2024-11-24 18:01 (UTC)
@qft Thanks a lot.
qft commented on 2024-11-24 15:42 (UTC)
hi @Ashark, thank you for your suggestion. I have changed the pkgver naming scheme as you suggested. There should be no downgrade warnings from now on.
Ashark commented on 2024-10-28 15:06 (UTC) (edited on 2024-10-28 15:11 (UTC) by Ashark)
Hi, qft. I see there is a problem with current versioning scheme. This is not your fault, but because of JetBrains themselves use it strangely. I was testing some previous versions (to see if some bug was presented there), and I again faced the problem of "fault downgrading".
I see I have already written about that problem previously (https://aur.archlinux.org/packages/pycharm-eap#comment-970401).
So, can you consider using such a naming scheme that is not dependent on their "release number". Just use the build number in the front always.
I.e. the problematic package versions are:
while I propose the following package versioning:
This way, the pycharm build number will be actually used by pacman when comparing versions, and this will be working correctly.
Edit: hypens are not allowed in the pkgver (see https://wiki.archlinux.org/title/PKGBUILD#pkgver), so I replaced it with underscore. And the wiki proposes that packagers actually do change the version "presentation" (for example, reversing the date format so year is in front) to make package version comparison correct.
1 2 3 4 5 6 .. 21 Next › Last »