[opensuse-python] 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-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+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
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/...).
I would vote for disabling python2 as far as possible as soon as possible. If there are difficult issues that require a python2 package to stay around, a separate python2 source package is imho the best solution as it at least makes it obvious where the issues are. The difficult part though is unfortunately due to the way the singlespec system is pulling in buildrequires, it requires a lot of fiddling to get rid of the reverse depends first. That leads to the larger question whether we really need to use singlespec for python 2.x only or python 3.x only questions. Sorry for asking the elefant-in-the-room question. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
On 2019-04-18, 14:01 GMT, Dirk Müller wrote:
I would vote for disabling python2 as far as possible as soon as possible. If there are difficult issues that require a python2 package to stay around, a separate python2 source package is imho the best solution as it at least makes it obvious where the issues are.
I completely agree. Moreover, as I have reported previously (https://lists.opensuse.org/opensuse-factory/2019-04/msg00229.html) we plan to remove Python 2 from Factory on January 1, 2020, so all attempts to keep python2-* packages around seems a bit wasteful. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 A GOOD name is rather to be chosen than great riches. -- Proverbs 22:1
On Thursday, June 20, 2019 11:31:48 PM CEST Matěj Cepl wrote:
Moreover, as I have reported previously (https://lists.opensuse.org/opensuse-factory/2019-04/msg00229.html) we plan to remove Python 2 from Factory on January 1, 2020, so all attempts to keep python2-* packages around seems a bit wasteful.
Are we in agreement that python3-XXX packages are good for Factory? I am not clear on that. It would certainly make my life a whole lot easier, as singlespec is difficult (pulls in a lot of python 2.x stuff) and makes collaboration with fedora less feasible. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
Dirk Mueller píše v Pá 21. 06. 2019 v 12:02 +0200:
On Thursday, June 20, 2019 11:31:48 PM CEST Matěj Cepl wrote:
Moreover, as I have reported previously (https://lists.opensuse.org/opensuse-factory/2019-04/msg00229.html) we plan to remove Python 2 from Factory on January 1, 2020, so all attempts to keep python2-* packages around seems a bit wasteful.
Are we in agreement that python3-XXX packages are good for Factory? I am not clear on that.
It would certainly make my life a whole lot easier, as singlespec is difficult (pulls in a lot of python 2.x stuff) and makes collaboration with fedora less feasible.
NO. We need singlespec as long as we plan to support older codestreams. And esp. since you guys backport a lot of stuff to older distributions it would make sense. Also we planned to allow people using the pypy with singlespec which should make some science people really happy. For us it means we will be more generous in writting '%define skip_python2 1' and simply not bother about its support if it is no longer feasible. Tom
On 2019-06-21, 10:02 GMT, Dirk Mueller wrote:
It would certainly make my life a whole lot easier, as singlespec is difficult (pulls in a lot of python 2.x stuff) and makes collaboration with fedora less feasible.
I would like to keep singlespec even AFTER python 2 dies and we switch off python2* macros. I still hope that we eventually make PyPy working and in my illegal-substance-induced dreams (that’s how close to reality it is) I can hope we can make Jython and/or IronPython working (or anything else which eventually comes). Current set of Python related macros is rather nice set, and I am strong supporter of when it is not broken, let it be. Concerning Fedora packages. I was Red Hat employee for eleven years, I packaged numerous Fedora/RHEL packages, including plenty of python-related ones. I hope we will never fall so low as to have packages comparable to Fedora. openSUSE packaging is leagues above Fedora ones, and we want to hope to maintain so many python-* packages with so few people as we do, we cannot settle for the unholy mess which is Fedora python-* SPEC files. What specific problems you have with singlespec packaging (aside from the presence of Python 2 compatible packages, which will evaporate in Januray, hopefully)? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 For those of you who think we are descendents from those cavemen who stood and fought with dinosaurs, you must be nuts, we are descendents from the ones who ran like hell to live.
On Saturday, June 29, 2019 10:18:36 AM CEST Tomas Chvatal wrote: Hi Tomas,
It would certainly make my life a whole lot easier, as singlespec is difficult (pulls in a lot of python 2.x stuff) and makes collaboration with fedora less feasible. NO. We need singlespec as long as we plan to support older codestreams.
What do you mean by older codestreams? sle12? or sle15? singlespec only works with sle12sp3 or newer, "older codestreams" are not having the right macros and the right version of macros. even sp3 is very painful. In the end it was easier to maintain non-singlespec packages for sle12. For sle15 this might be true though most packages I've seen as singlespec did not actually work in python 2.x only mode (or in 3.x only mode in some cases, although things were generally better there). That being said we made the unfortunate choice to use singlespec for the packaging CI, and there we're now switching to python 3 only, so singlespec only makes problems doesn't solve any (most recent breaking everything example is the rename of python-Sphinx to python-Sphinx1 ).
And esp. since you guys backport a lot of stuff to older distributions it would make sense.
I'm afraid that is no longer relevant with the shift of focus to sle15 where python 3.6 is available (which is good enough for most dependencies) and the only elligible python anyway in less than 6 months from now.
Also we planned to allow people using the pypy with singlespec which should make some science people really happy.
Do they need all 1000+ packages as pypy versions? How likely is it that they all work with pypy? I would be curious to see an experiement on this.
For us it means we will be more generous in writting '%define skip_python2 1' and simply not bother about its support if it is no longer feasible.
Yep, which makes the python 2.x compatible package disappear, breaking every singlespec package that depends on it. Exactly these generous "skip_python2" settings that get checked into tumbleweed are causing most of the problems right now. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
Dirk Mueller píše v Čt 04. 07. 2019 v 15:55 +0200:
On Saturday, June 29, 2019 10:18:36 AM CEST Tomas Chvatal wrote:
Hi Tomas,
It would certainly make my life a whole lot easier, as singlespec is difficult (pulls in a lot of python 2.x stuff) and makes collaboration with fedora less feasible. NO. We need singlespec as long as we plan to support older codestreams.
What do you mean by older codestreams? sle12? or sle15? singlespec only works with sle12sp3 or newer, "older codestreams" are not having the right macros and the right version of macros. even sp3 is very painful.
All the macros were synced by me to the latest python-rpm-macros and were released properly in IBS. You can use them all quite fine if you build against the :Update and not against :GA.
In the end it was easier to maintain non-singlespec packages for sle12. For sle15 this might be true though most packages I've seen as singlespec did not actually work in python 2.x only mode (or in 3.x only mode in some cases, although things were generally better there).
I synced this couple of months ago when I noticed it was not synced, because I thought you guys did it whenever more stuff was added to Cloud modules. We would've done it even before if you told us. So now on IBS the macros are at the latest version in SLE12:Update and all codestreams are able to work with it.
That being said we made the unfortunate choice to use singlespec for the packaging CI, and there we're now switching to python 3 only, so singlespec only makes problems doesn't solve any (most recent breaking everything example is the rename of python-Sphinx to python-Sphinx1 ).
So your CI is picking just selective packages or what is the issue? The Sphinx1 i didn't call as python2-Sphinx because I expected you guys to enable the python3 again because you would still need it, as last upgrade of Sphinx it was reverted few times to get you to migrate). The same rationale I am now doing with the pytest (adding pytest3 and pytest4) because some software still needs the pytest3 on python3...
And esp. since you guys backport a lot of stuff to older distributions it would make sense.
I'm afraid that is no longer relevant with the shift of focus to sle15 where python 3.6 is available (which is good enough for most dependencies) and the only elligible python anyway in less than 6 months from now.
We still happen to have bunch of SLE12 requests
Also we planned to allow people using the pypy with singlespec which should make some science people really happy.
Do they need all 1000+ packages as pypy versions? How likely is it that they all work with pypy? I would be curious to see an experiement on this.
Quite big load of them really work (some need minor tweaks in build commands), we just didn't have time to enable it. When singlespec was created it was with this in mind actually, because we knew that the python2 will hopefully die quickly.
For us it means we will be more generous in writting '%define skip_python2 1' and simply not bother about its support if it is no longer feasible.
Yep, which makes the python 2.x compatible package disappear, breaking every singlespec package that depends on it. Exactly these generous "skip_python2" settings that get checked into tumbleweed are causing most of the problems right now.
Hmm this can cause trouble for you, but they stay resolvable for TW so how can we change this. Because we are not dropping any stuff when we do the skip python, with the naming I always add another package that provides the older version that still provides python2 and everything stays resolvable on TW. Should we email somewhere to notify you guys about new deps? Or can we tag it somewhere? Cheers Tom
Hi, On 7/4/19 4:29 PM, Tomas Chvatal wrote: [...]
Also we planned to allow people using the pypy with singlespec which should make some science people really happy.
Do they need all 1000+ packages as pypy versions? How likely is it that they all work with pypy? I would be curious to see an experiement on this.
Quite big load of them really work (some need minor tweaks in build commands), we just didn't have time to enable it. When singlespec was created it was with this in mind actually, because we knew that the python2 will hopefully die quickly.
How can things work for non-python3 when we have plenty of: %python3_only %{_bindir}/foorun in the %files sections? Or does "working" mean "build succeeds" ? Best, Tom -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
On Thursday, July 4, 2019 4:29:45 PM CEST Tomas Chvatal wrote: Hi Tomas,
All the macros were synced by me to the latest python-rpm-macros and were released properly in IBS. You can use them all quite fine if you build against the :Update and not against :GA.
just look at dlp:backports yourself. example package python-mox3.
only makes problems doesn't solve any (most recent breaking everything example is the rename of python-Sphinx to python-Sphinx1 ). So your CI is picking just selective packages or what is the issue?
by renaming the package to python-sphinx1, python2-sphinx was disappearing and instead we got the stone old python2-sphinx from SLE15:GA, which was obviously missing the fixes for python 3.x enablement, so no package on SLE15:SLE15 etc was building anymore. I really didn't understand this, so I reverted this rename, which fixes the problem.
The Sphinx1 i didn't call as python2-Sphinx because I expected you guys to enable the python3 again because you would still need it, as last upgrade of Sphinx it was reverted few times to get you to migrate).
did you tell anyone of "us" what the issue is? :-) if so, what is the issue ?
Do they need all 1000+ packages as pypy versions? How likely is it that they all work with pypy? I would be curious to see an experiement on this.
Quite big load of them really work (some need minor tweaks in build commands), we just didn't have time to enable it. When singlespec was created it was with this in mind actually, because we knew that the python2 will hopefully die quickly.
I really can't imagine how this would work with how singlespec works at the moment (building yes, working no).
Because we are not dropping any stuff when we do the skip python, with the naming I always add another package that provides the older version that still provides python2 and everything stays resolvable on TW.
I think keeping the old package as python2-$foo would generally work if it is needed by anything.
Should we email somewhere to notify you guys about new deps? Or can we tag it somewhere?
Yes, some coordination before things break would be really great, how about just starting a mail discussion here? Greetings, Dirk
Cheers
Tom
-- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
Thomas Bechtold píše v Pá 05. 07. 2019 v 09:04 +0200:
Hi,
On 7/4/19 4:29 PM, Tomas Chvatal wrote:
[...]
Also we planned to allow people using the pypy with singlespec which should make some science people really happy.
Do they need all 1000+ packages as pypy versions? How likely is it that they all work with pypy? I would be curious to see an experiement on this.
Quite big load of them really work (some need minor tweaks in build commands), we just didn't have time to enable it. When singlespec was created it was with this in mind actually, because we knew that the python2 will hopefully die quickly.
How can things work for non-python3 when we have plenty of:
%python3_only %{_bindir}/foorun
in the %files sections? Or does "working" mean "build succeeds" ?
For most of the stuff you don't need the binaries, you want the modules to work. And alsoy you can always just do something along the lines of 'python -m whatever' and get same behaviour like with the binary that is not shipped. The scripts are mostly just wrappers that do it conveniently for you. Cheers Tom
Dirk Mueller píše v Pá 05. 07. 2019 v 18:32 +0200:
On Thursday, July 4, 2019 4:29:45 PM CEST Tomas Chvatal wrote:
Hi Tomas,
All the macros were synced by me to the latest python-rpm-macros and were released properly in IBS. You can use them all quite fine if you build against the :Update and not against :GA.
just look at dlp:backports yourself. example package python-mox3.
only makes problems doesn't solve any (most recent breaking everything example is the rename of python-Sphinx to python-Sphinx1 ). So your CI is picking just selective packages or what is the issue?
by renaming the package to python-sphinx1, python2-sphinx was disappearing and instead we got the stone old python2-sphinx from SLE15:GA, which was obviously missing the fixes for python 3.x enablement, so no package on SLE15:SLE15 etc was building anymore.
I really didn't understand this, so I reverted this rename, which fixes the problem.
The Sphinx1 i didn't call as python2-Sphinx because I expected you guys to enable the python3 again because you would still need it, as last upgrade of Sphinx it was reverted few times to get you to migrate).
did you tell anyone of "us" what the issue is? :-) if so, what is the issue ?
Do they need all 1000+ packages as pypy versions? How likely is it that they all work with pypy? I would be curious to see an experiement on this.
Quite big load of them really work (some need minor tweaks in build commands), we just didn't have time to enable it. When singlespec was created it was with this in mind actually, because we knew that the python2 will hopefully die quickly.
I really can't imagine how this would work with how singlespec works at the moment (building yes, working no).
Because we are not dropping any stuff when we do the skip python, with the naming I always add another package that provides the older version that still provides python2 and everything stays resolvable on TW.
I think keeping the old package as python2-$foo would generally work if it is needed by anything.
Should we email somewhere to notify you guys about new deps? Or can we tag it somewhere?
Yes, some coordination before things break would be really great, how about just starting a mail discussion here?
Ok, So in order to make it happily work we need to have some safeguards to not explode your stuff. 1) announce all new added compat packages here on the mailinglist in a form of 'python2-whatever was added to d:l:py:numeric' as a headsup. 2) we need to regen the :backports repo from TW not cron-based but more like release based. Thus whenever new snapshot from TW is added we should regen the :backports. Any idea how to do this? The point 1 takes care of at least some form of notification, but in the end TW integration/stagings might take different time until it propagates completely inside... Cheers Tom
On 2019-07-05, 07:04 GMT, you wrote:
How can things work for non-python3 when we have plenty of:
%python3_only %{_bindir}/foorun
in the %files sections? Or does "working" mean "build succeeds" ?
What’s wrong with %python3_only for files in %{_bindir}? Logic behind this is usually: we have python2 compatible library for all python2 programs they need it, and if you need running command foorun, then you usually don’t care whether it uses python2 or python3 in the background, you just want to run it. We can of course do alternatives for all those foorun commands, but it is usually too much bother, and I am really not sure what’s wrong with this logic. What do you think? Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If we rise from prayer better persons, our prayers have been answered. -- a Jewish prayer book -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
On 7/8/19 2:42 PM, Matěj Cepl wrote:
On 2019-07-05, 07:04 GMT, you wrote:
How can things work for non-python3 when we have plenty of:
%python3_only %{_bindir}/foorun
in the %files sections? Or does "working" mean "build succeeds" ?
What’s wrong with %python3_only for files in %{_bindir}?
Logic behind this is usually: we have python2 compatible library for all python2 programs they need it, and if you need running command foorun, then you usually don’t care whether it uses python2 or python3 in the background, you just want to run it.
I *do* care. I don't want to install the whole python3 requirements just for running a command. And with all this %python3_only, commands will not work for python2 (which will die anyway) and pypy (the statement was that on pypy most things just work).
We can of course do alternatives for all those foorun commands, but it is usually too much bother, and I am really not sure what’s wrong with this logic.
That you can not run commands in py2/pypy-only environments. Best, Tom -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
Hi, On 7/8/19 10:34 AM, Tomas Chvatal wrote:
Thomas Bechtold píše v Pá 05. 07. 2019 v 09:04 +0200:
Hi,
On 7/4/19 4:29 PM, Tomas Chvatal wrote:
[...]
Also we planned to allow people using the pypy with singlespec which should make some science people really happy.
Do they need all 1000+ packages as pypy versions? How likely is it that they all work with pypy? I would be curious to see an experiement on this.
Quite big load of them really work (some need minor tweaks in build commands), we just didn't have time to enable it. When singlespec was created it was with this in mind actually, because we knew that the python2 will hopefully die quickly.
How can things work for non-python3 when we have plenty of:
%python3_only %{_bindir}/foorun
in the %files sections? Or does "working" mean "build succeeds" ?
For most of the stuff you don't need the binaries, you want the modules to work.
I have a completely different opinion. If I don't have the executables, why do I need the modules? I *want* the executables available for the pyversion I use (eg. python3, python2 or pypy).
And alsoy you can always just do something along the lines of 'python -m whatever' and get same behaviour like with the binary that is not shipped. The scripts are mostly just wrappers that do it conveniently for you.
Sounds really user-friendly on a py2/pypy stack... Cheers, Tom -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
Thomas Bechtold píše v Po 08. 07. 2019 v 15:45 +0200:
I *do* care. I don't want to install the whole python3 requirements just for running a command.
Sorry, that you are not an intended user of openSUSE (and besides, you will be out of luck on January 1 anyway). For this detailed control of packages, you will probably be better served by Gentoo or something similar.
… and pypy (the statement was that on pypy most things just work).
BTW, it should theoretically work, unfortunately both https://build.opensuse.org/package/show/devel:languages:python:Factory/pypy2 and https://build.opensuse.org/package/show/devel:languages:python:Factory/pypy3 are broken. Requests with fixes and upgrades to the latest versions of those packages are more than welcome (especially, pypy3). Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Never, never, never believe any war will be smooth and easy, or that anyone who embarks on the strange voyage can measure the tides and hurricanes he will encounter. The statesman who yields to war fever must realise that once the signal is given, he is no longer the master of policy but the slave of unforeseeable and uncontrollable events. -- Winston Churchill, 1930
Hi, On 7/8/19 4:15 PM, Matěj Cepl wrote:
Thomas Bechtold píše v Po 08. 07. 2019 v 15:45 +0200:
I *do* care. I don't want to install the whole python3 requirements just for running a command.
Sorry, that you are not an intended user of openSUSE (and besides, you will be out of luck on January 1 anyway).
I thought the discussion is also about pypy (so the 1 Jan argument doesn't count imo). For this
detailed control of packages, you will probably be better served by Gentoo or something similar.
Detailed control? I just want working packages which include the executables. And all other distros I looked at (Fedora, Debian, Ubuntu) just have the executables for all python versions. Cheers, Tom
On 2019-07-09, 06:32 GMT, you wrote:
I thought the discussion is also about pypy (so the 1 Jan argument doesn't count imo).
Right, that one doesn’t apply, but the rest is the same: normal users can use whatever they have in %{_bindir} (and python3 is probably the basic Python for many years to come), and whoever needs the library can use it with python2/pypy/etc. And yes, ``pypy -m library`` trick should work as well.
Detailed control? I just want working packages which include the executables. And all other distros I looked at (Fedora, Debian, Ubuntu) just have the executables for all python versions.
If you have some more important reason than “I don’t want to have Python 3 on my system” we can certainly add alternatives for the particular packages, but I don’t think I would like to add foo-2 and foo-3 versions to all python packages in the repository. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If we rise from prayer better persons, our prayers have been answered. -- a Jewish prayer book -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
On Tuesday, July 9, 2019 1:14:17 PM CEST Matěj Cepl wrote: Hi Matej,
If you have some more important reason than “I don’t want to have Python 3 on my system” we can certainly add alternatives for the particular packages, but I don’t think I would like to add foo-2 and foo-3 versions to all python packages in the repository.
I believe there might be a misunderstanding, and I think Tom wasn't actually that difficult to understand. The discussion is about getting rid of singlespec because (as you rightly pointed out that python 2.x is nearing EOL). This was countered with the point that you want to have singlspec so that pypy works, and this raised the eyebrows because the current singlespec approach won't work for pypy. And there were a lot of reasons given why it wouldn't be relevant to have working packages and that there are obscure workarounds (which require a ton of patching in other code that needs to be using the obscure workarounds instead of just using the bindir binary as it exists properly packaged on every sane distribution (opensuse excluded) on the whole planet. Neither Tom nor I want python 2.x only stack. we want a python 3.x only stack without the insane baggage that singlespec carries behind it (where everything needs to be enabled for all enabled python interpreters). Greetings, Dirk -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
On 2019-07-09, 12:35 GMT, you wrote:
I believe there might be a misunderstanding, and I think Tom wasn't actually that difficult to understand.
Yes, there is, we are crossing two streams (OH NO!) of communication. You are replying to my discussion with Thomas Bechtold, and arguing about something else.
The discussion is about getting rid of singlespec because (as you rightly pointed out that python 2.x is nearing EOL).
That’s the discussion I have with you.
This was countered with the point that you want to have singlspec so that pypy works, and this raised the eyebrows because the current singlespec approach won't work for pypy.
That is not correct. The current singlespec works with pypy (or at least we have no reasons to believe it doesn’t work), but pypy and pypy3 themselves are broken. When somebody fixes pypy3, we could use all thousands manhours of fixing our current python SPEC files with that as well, and not pour them down the drain as you seem to like to do.
Neither Tom nor I want python 2.x only stack. we want a python 3.x only stack without the insane baggage that singlespec carries behind it (where everything needs to be enabled for all enabled python interpreters).
That is a different discussion I have with Thomas (not Tomáš Chvátal … too many Toms in one discussion!), and what I understood python2-only stack is exactly what he wants, doesn’t it? To have python2-programs in %{_bindir}? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 When you're happy that cut and paste actually works I think it's a sign you've been using X-Windows for too long. -- from /. discussion on poor integration between KDE and GNOME -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
Hey, On 7/9/19 1:14 PM, Matěj Cepl wrote:
On 2019-07-09, 06:32 GMT, you wrote:
I thought the discussion is also about pypy (so the 1 Jan argument doesn't count imo).
Right, that one doesn’t apply, but the rest is the same: normal users can use whatever they have in %{_bindir} (and python3 is probably the basic Python for many years to come), and whoever needs the library can use it with python2/pypy/etc. And yes, ``pypy -m library`` trick should work as well.
That "trick" mean you need to patch all your scripts that rely on executables from /usr/bin . That will not work. Another problem with this trick is: $ python3 -m novaclient /usr/bin/python3: No module named novaclient.__main__; 'novaclient' is a package and cannot be directly executed So you first need to find out (I know how to, just an example) which module contains main.
Detailed control? I just want working packages which include the executables. And all other distros I looked at (Fedora, Debian, Ubuntu) just have the executables for all python versions.
If you have some more important reason than “I don’t want to have Python 3 on my system” we can certainly add alternatives for the particular packages, but I don’t think I would like to add foo-2 and foo-3 versions to all python packages in the repository.
I want to have python3. Actually But if I want to have pypy (or python2), I don't want to have the whole python3 stack just for the executables (which would then anyway call the python3 code, and not the pypy/python2 code). I can currently see 3 possible solutions: 1) keep the current status (use singlespec, no executables in pypy/python2 modules). I hope it's obvious that I don't prefer this solution :) 2) add executables to all flavors. So using %python3_only is no longer allowed. The packages would use the update-alternative mechanism to provide the executables for python3/python2/pypy 3) Remove singlespec and only care about python3 I would prefer 3) over 2) over 1) because I only care about python3 and singlespec makes the whole thing more complicated than needed. Cheers, Tom
On Tuesday, July 9, 2019 7:56:12 PM CEST Matěj Cepl wrote: Hi Matej,
Yes, there is, we are crossing two streams (OH NO!) of communication. You are replying to my discussion with Thomas Bechtold, and arguing about something else.
I'm not yet arguing, we're still exchanging information.
This was countered with the point that you want to have singlspec so that pypy works, and this raised the eyebrows because the current singlespec approach won't work for pypy. That is not correct. The current singlespec works with pypy (or at least we have no reasons to believe it doesn’t work)
Thats where the two streams of communication are interconnected. We know that singlespec can build for multiple python flavors, but actualyl working (if you're lucky) is only the python3 flavors. others are usually not. the example of a singlespec stack where you only care about python2 is equally valid to a pypy stack where you only care about pypy. Furthermore, due to the approach that singlespec is been taken (pull in all the dependencies into the buildenvironment, build multipl times) it is actually hiding a lot of the problems you hit when you *actually* *use* those packages. as an example a module or script that calls /usr/bin/python somewhere deep inside its code will always pass %check testing in singlespec because /usr/ bin/python is there. In a real system it will just break because it isn't guaranteed for python 2.x to be installed.
, but pypy and pypy3 themselves are broken.
Oh great, so we keep singlespec for the pypy usecase but we know that pypy usecase doesn't actually work right now?
carries behind it (where everything needs to be enabled for all enabled python interpreters). That is a different discussion I have with Thomas (not Tomáš Chvátal … too many Toms in one discussion!), and what I understood python2-only stack is exactly what he wants, doesn’t it? To have python2-programs in %{_bindir}?
Not really, see his reply. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
participants (9)
-
Dirk Mueller
-
Dirk Müller
-
Matej Cepl
-
Matěj Cepl
-
Thomas Bechtold
-
Thomas Bechtold
-
Todd Rme
-
Tomas Chvatal
-
Tomas Chvatal