Search Criteria
Package Details: pycharm-eap 243.22562.220_2024.3.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.014827 |
First Submitted: | 2011-05-06 08:33 (UTC) |
Last Updated: | 2024-12-21 00:18 (UTC) |
Dependencies (12)
- cython (cython-gitAUR, cython0AUR) (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-dotconfigAUR, openssh-dotconfig-binAUR, openssh-selinuxAUR, openssh-hpn-shimAUR, openssh-gssapiAUR, openssh-dnatAUR) (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
- vagrant (vagrant-gitAUR) (optional) – For support virtualized development environments
Latest Comments
1 2 3 4 5 6 .. 21 Next › Last »
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
1
ensures 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
2024
is 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.
qft commented on 2024-06-08 03:36 (UTC)
This issue will be fixed in the next release as well.
Ashark commented on 2024-06-07 17:22 (UTC) (edited on 2024-06-07 17:39 (UTC) by Ashark)
When debugging, I see in the terminal the message repeated lots of times:
I have checked the package, and there really is no such file:
But I see this file exists in the official community package (https://archlinux.org/packages/extra/x86_64/pycharm-community-edition/):
also, I see that file in the pycharm-community-eap (https://aur.archlinux.org/packages/pycharm-community-eap)
@qft, I guess it is the packaging issue. Can you please check?
I see that the source archive (downloaded from jetbrains website) actually has the file in question. But the PKGBUILD has this line, which just deletes everything:
qft commented on 2024-06-06 00:51 (UTC)
It will be fixed with the next release.
1 2 3 4 5 6 .. 21 Next › Last »