Hi,
some while ago, @flying-sheep passed on their `pycharm-community-eap` package to me, which I have been co-maintaining for a while at that point. Recently, I got a user request to remove the (make) dependency to `python2-setuptools`- which was used to pre-compile a Python 2 debugger provided from upstream - or make it optional.
Since on the one hand I agree that deprecating Python 2 is a good thing, but on the other hand there might be users who still (need to) work with Python 2, I'm wondering if and how to make a compromise would be the best way to go. There's no way to declare optional make-dependecies as far as I'm aware.
For the time being I've removed the makedep, but also have implemented a check in the `PKGBUILD` if `python2-setuptools` is installed anyways and under that condition, the precompiled Python 2 debugger is included.
I'm not sure about this anyways, especially in regard to the official `pycharm-community-edition` package in the `community` repo, which does still depend on `python2-setuptools` at build time. Hence my query to the mailing list asking for opinions/recommendations how I should handle this. Any thoughts are welcome.
Thanks in advance !
- Kr1ss -
I had the same issue with the `medit` package. It's an editor with some nice features, in particular, an integrated bash terminal. I have been pointed to the fact that pygtk is deprecated some months ago, but removing pygtk as dependency leads to the bash terminal functionality vanishing. I decided to keep the dependency for now, but I am open for opinions!
On 8/27/20 11:11 AM, Michael Kogan wrote:
I had the same issue with the `medit` package. It's an editor with some nice features, in particular, an integrated bash terminal. I have been pointed to the fact that pygtk is deprecated some months ago, but removing pygtk as dependency leads to the bash terminal functionality vanishing. I decided to keep the dependency for now, but I am open for opinions!
That's a bit of a different case though. If major core features depend on the python2 dependency, it makes sense to keep them.
It's more of a question with pycharm, because the only thing you gain in pycharm is... the ability to edit/manipulate python2 code using it.
With medit, everyone would lose out on the integrated terminal. This seems like a clear case to continue shipping it.
With pycharm, only people developing on legacy python2 codebases lose out. Hence why it's a question.
Am 27.08.2020 17:01, schrieb Kr1ss via aur-general:
I'm not sure about this anyways, especially in regard to the official `pycharm-community-edition` package in the `community` repo, which does still depend on `python2-setuptools` at build time. Hence my query to the mailing list asking for opinions/recommendations how I should handle this. Any thoughts are welcome.
I feel that Arch always has been a progressive distro and we should move on from Python2. But: don't make it too hard for people patching in the required feature. Basically just comment out what is needed and write an explanation on how to reenable it. This way it is out of the way of those who don't use Py2 anymore, but quickly available for those still in need of it. This is a bit different for binary repos, where everything is build in a clean chroot and (if I understand correctly) running it does not depend on py2 as long as you don't use the feature.
best Georg
On Thu, Aug 27, 2020 at 05:26:30PM +0200, Georg wrote:
Am 27.08.2020 17:01, schrieb Kr1ss via aur-general:
I'm not sure about this anyways, especially in regard to the official `pycharm-community-edition` package in the `community` repo, which does still depend on `python2-setuptools` at build time. Hence my query to the mailing list asking for opinions/recommendations how I should handle this. Any thoughts are welcome.
I feel that Arch always has been a progressive distro and we should move on from Python2. [ ... ] This is a bit different for binary repos, where everything is build in a clean chroot and (if I understand correctly) running it does not depend on py2 as long as you don't use the feature.
- End of Quote -
Good point. I guess the PKGBUILD is okay then, since it neither gets in the way of the python2-fraction nor the non-python2 users. Thanks a lot everone. Cheers !
-- - Kr1ss -
aur-general@lists.archlinux.org