[opensuse-factory] Upstreams dropping python2
Over the next year we are going to start seeing more and more upstreams that are dependencies for a lot of other packages drop python2 support. Some have already done it (sympy, matplotlib, django), others have plans in place to do it over the next few months (numpy, pandas), while others will randomly drop python2 support with little or no warning. We probably should decide on a real policy now how to handle this. I see two main approaches: 1. Keep a python2-foo package that sticks with the last python2 compatible version. 2. Switch all packages that have a hard dependency on it to also be python3 only. Up to this point this has been handled somewhat arbitrarily on a case-by-case basis. So for example we keep a python2-matplotlib, but not python2-astropy. I think we would benefit from having a clear policy on how to handle this. Does anyone have an opinion on what it should be? Personally, since according to upstream at least we should be transitioning to python3-only, I would favor dropping all python2-foo packages and having packages that depend on python3-only packages be python3-only, with special exceptions possible on a case-by-case basis. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Todd Rme píše v St 17. 04. 2019 v 16:08 -0400:
Over the next year we are going to start seeing more and more upstreams that are dependencies for a lot of other packages drop python2 support. Some have already done it (sympy, matplotlib, django), others have plans in place to do it over the next few months (numpy, pandas), while others will randomly drop python2 support with little or no warning. We probably should decide on a real policy now how to handle this.
I see two main approaches:
1. Keep a python2-foo package that sticks with the last python2 compatible version. 2. Switch all packages that have a hard dependency on it to also be python3 only.
Up to this point this has been handled somewhat arbitrarily on a case-by-case basis. So for example we keep a python2-matplotlib, but not python2-astropy.
I think we would benefit from having a clear policy on how to handle this. Does anyone have an opinion on what it should be?
Personally, since according to upstream at least we should be transitioning to python3-only, I would favor dropping all python2-foo packages and having packages that depend on python3-only packages be python3-only, with special exceptions possible on a case-by-case basis.
Hi, In general for now we don't have many of the python2-bla packages and you are right that this number will continue to grow. I just checked what is in the current TW: python2-astroid.spec python2-cmd2.spec python2-GooCalendar.spec python2-gsw.spec python2-jupyter_console.spec python2-jupyter_ipykernel.spec python2-jupyter_ipython.spec python2-matplotlib.spec python2-oscfs.spec python2-pylint.spec python2-PyX.spec At the moment I always added it only on stuff that had many reverse dependencies and it would hurt deeply the py2 users like with the astroid/gsw/pylint/matplot... In general I agree we should go with upstream and convert to py3 only variant but in a case where it has many reverse depenedencies we should create py2 only fork with the older version. Here we should prolly create some dlpy:python2 subproject were we could keep all the weird compat versions in place and we can even see if community is really that keen to maintain that. Or another alternative is to go brutal like Fedora is going and disable python2 everywhere and keep it only in a cases where it is really needed (ie for building firefox/...). Cheers Tom
participants (2)
-
Todd Rme -
Tomas Chvatal