tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now.
Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 – many more than we can support without upstream help. We (rightly) don't have the authority to say "please drop your unneeded python2 subpackages, or let us drop them for you" [0]. The next best thing we *can* say is: "if Fedora is to keep python2 alive, we won't be the ones doing it – at least not at the current magnitude". Here are the details.
The current maintainers of python2 would like to "orphan" the python2 package in 2020 (~ Fedora 30): - Charalampos Stratakis (cstratak) - Tomáš Orsava (torsava) - Miro Hrnočok (churchyard) - Petr Viktorin (pviktori) - Iryna Schcherbina (ishcherb) - Michal Cyprian (mcyprian) - Bohuslav Kabrda (bkabrda) - David Malcolm (dmalcolm) - Thomas Spura (tomspur)
As with any orphaning, that leaves two options: - someone else agrees now to take over in 2020 (keeping in mind this is a security-critical package and will be abandoned upstream), or - dependent packages drop support for Python 2.
Unlike most other orphanings, we have some thousands of dependent packages, so a lot of time and care is required. In case no one steps up, we'd like to start dropping Python 2 support from dependent packages *now*, starting with ported libraries on whose python2 version nothing in Fedora depends. (We keep a list of those at [1].) Of course, we're ready to make various compromises with interested packagers, as long as there's an understanding that we won't just support python2 forever.
If you are a maintainer of anything at [1] we ask you kindly to consider removing the python2 subpackages. You can either do it now in Rawhide, or add a conditional for Fedora > 29. (On the current schedule, Fedora 30 will be the first release still supported after 2020-01-01.)
If no one steps up to maintain python2 after 2020, we're prepared to package a "legacy" python27 package, similar to what we do for e.g. python33 [2], to: - help developers that still need to test against this version - support exceptionally important non–security critical applications, if their upstreams don't manage to port to Python 3 in time
[0] https://pagure.io/packaging-committee/issue/753 [1] http://fedora.portingdb.xyz/#legacy-leaf [2] https://src.fedoraproject.org/rpms/python33/
On 2018-03-23, 11:23 GMT, Petr Viktorin wrote:
Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance.
Just a note of warning: don’t to be too over-eager with dropping everything Python 2 related in EPEL-7. Its EOS is only sometime after 2024 (https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle) and the question whether the packages which can use both Python2 and Python3 as its dependency (e.g., youtube-dl) should switch to Python3 or use the base RHEL-provided Python 2.7.
Best,
Matěj
On Fri, Mar 23, 2018 at 7:29 AM, Matěj Cepl mcepl@cepl.eu wrote:
Just a note of warning: don’t to be too over-eager with dropping everything Python 2 related in EPEL-7. Its EOS is only sometime after 2024 (https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle) and the question whether the packages which can use both Python2 and Python3 as its dependency (e.g., youtube-dl) should switch to Python3 or use the base RHEL-provided Python 2.7.
And please don't start dropping python 2 subpackages that are actually used by other packages in Fedora without talking to the maintainers first. I just got bitten by this change to python-nose-cov:
* Thu Mar 22 2018 John Dulaney jdulaney@fedoraproject.org - 1.6-13 - Drop python2 subpackage
And now koschei is sending me emails about how all of my packages that use python-nose-cov have broken dependencies in Rawhide. I'm not ready to drop python2 support for those packages yet; they are dependencies of still other packages. We need to start this process from the leaves and work back towards the roots, not the other way around.
For each of these, I can of course simply run %check for the python3 subpackage, and skip the python2 subpackage, but then breakages to the python2 subpackage might go unnoticed.
On 23.3.2018 15:16, Jerry James wrote:
And please don't start dropping python 2 subpackages that are actually used by other packages in Fedora without talking to the maintainers first. I just got bitten by this change to python-nose-cov:
- Thu Mar 22 2018 John Dulaney jdulaney@fedoraproject.org - 1.6-13 -
Drop python2 subpackage
And now koschei is sending me emails about how all of my packages that use python-nose-cov have broken dependencies in Rawhide. I'm not ready to drop python2 support for those packages yet; they are dependencies of still other packages. We need to start this process from the leaves and work back towards the roots, not the other way around.
Exactly. You can check if your package is a leaf at [1].
[1] http://fedora.portingdb.xyz/#legacy-leaf
For each of these, I can of course simply run %check for the python3 subpackage, and skip the python2 subpackage, but then breakages to the python2 subpackage might go unnoticed.
Please don't do hacks. Non-leaf packages should not be removed (at least not without prior talk to your dependent packages maintainers). If a maintainer removes a non-leaf package, please report to them that they break things (like you just did, thank you).
On 03/23/2018 12:23 PM, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now.
Bummer - I am speechless.
Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 – many more than we can support without upstream help.
Correct.
Face it, your plan is naive and has failed even before it begun.
Ralf
On Fri, Mar 23, 2018 at 04:07:51PM +0100, Ralf Corsepius wrote:
On 03/23/2018 12:23 PM, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now.
Bummer - I am speechless.
Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 – many more than we can support without upstream help.
Correct.
Face it, your plan is naive and has failed even before it begun.
As well as being rude, I think you're wrong on a technical level, and that's a shame because I generally respect your (often contrarian) viewpoint on this list.
I see a number of problems with Python 2:
- Packaging two versions of Python is painful. See for example the hoops we have to go through both upstream & downstream for hivex (as one example, others include: virt-v2v, libguestfs, virt-* tools).
- Python 2 also has a bunch of serious deficiencies dealing with UTF-8 strings which are largely fixed in 3.
I'm not personally a fan of either variant of the language - it's silly that we let programmers use an unsafe, slow, interpreted scripting language when we've known how to make better programming environments for at least 40 years.
But it's hard to argue with a plan which has been pre-announced *2 years* in advance. If only all Fedora changes were given such a generous runway.
Rich.
On 2018-03-24, 15:09 GMT, Richard W.M. Jones wrote:
I'm not personally a fan of either variant of the language
- it's silly that we let programmers use an unsafe, slow, interpreted
scripting language when we've known how to make better programming environments for at least 40 years.
Just curious: better programming environments … such us?
Best,
Matěj
On Sat, Mar 24, 2018 at 08:56:02PM +0100, Matěj Cepl wrote:
On 2018-03-24, 15:09 GMT, Richard W.M. Jones wrote:
I'm not personally a fan of either variant of the language
- it's silly that we let programmers use an unsafe, slow, interpreted
scripting language when we've known how to make better programming environments for at least 40 years.
Just curious: better programming environments … such us?
Anything in the ML family of course.
Rich.
Hi everyone,
First, I agree with Richard that packaging two versions is painful. It's also confusing from the other side. "Install Python. I already have it. No, that's Python2, you need Python3. (O_O)" Second, I think the earlier we start the better. So there's time to cut leafs and replace old libraries in Python2 with equivalents in Python3, dropping packages, etc. By the time, Python2 is definitely deprecated, most of the work is done and only some details remain. Third, upgrading packages and changing dependencies is no minor tasks. With time, it can be done silently with testing enough so there are no major issues. Side question, what is ML?
Kind regards, Silvia FAS:Lailah
On 24 March 2018 at 23:12, Richard W.M. Jones rjones@redhat.com wrote:
On Sat, Mar 24, 2018 at 08:56:02PM +0100, Matěj Cepl wrote:
On 2018-03-24, 15:09 GMT, Richard W.M. Jones wrote:
I'm not personally a fan of either variant of the language
- it's silly that we let programmers use an unsafe, slow, interpreted
scripting language when we've known how to make better programming environments for at least 40 years.
Just curious: better programming environments … such us?
Anything in the ML family of course.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~ rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Silvia Sánchez wrote:
First, I agree with Richard that packaging two versions is painful. It's also confusing from the other side. "Install Python. I already have it. No, that's Python2, you need Python3. (O_O)"
The packages are already renamed or being renamed to python2*, and the plan is also to switch the Provides so that python3 will be the package Providing python, not python2. That should solve that issue without having to nuke python2.
Second, I think the earlier we start the better. So there's time to cut leafs and replace old libraries in Python2 with equivalents in Python3, dropping packages, etc. By the time, Python2 is definitely deprecated, most of the work is done and only some details remain.
I am strongly opposed to removing working software that is still useful for users. There is certainly very useful niche software that has not been ported to Python 3 yet.
I am all for kicking out Python 2 from things such as live images if it is still on them, for space reasons. But I think it needs to remain available in the repository.
Kevin Kofler
On 25.3.2018 14:25, Kevin Kofler wrote:
I am all for kicking out Python 2 from things such as live images if it is still on them, for space reasons. But I think it needs to remain available in the repository.
And we are not saying "python2 needs to get out", we are saying "somebody needs to take care of it, we are stepping down (or it needs to get out if nobody is willing to do that)".
We are also saying "think about your python2-foo packages, do you consider them still useful? if not, nuke them at will, but our recommendation is Fedora 29 or 30"
On Sat, Mar 24, 2018 at 08:56:02PM +0100, Matěj Cepl wrote:
On Sat, 24 Mar 2018 23:12:31 +0000 "Richard W.M. Jones" rjones@redhat.com wrote:
Just curious: better programming environments … such us?
Anything in the ML family of course.
So, in looking it up, those languages have been around for almost 50 years, and they haven't "caught on". Why? Programmers are usually quick to pick up something which is better. What is it about ML family languages that have caused them to be passed over?
I tried programming in lisp a long time ago, and found it was not a good fit for the way I think about programming solutions because of its functional nature. Is that the reason for most people? To put it another way, if people don't cut their teeth on declarative languages, if their first exposure to programming is via a functional language, do they then embrace functional programming? Or is it like right and left handedness, inherent in people, with the majority preferring declarative?
On 03/23/2018 07:23 AM, Petr Viktorin wrote:
In case no one steps up, we'd like to start dropping Python 2 support from dependent packages *now*, starting with ported libraries on whose python2 version nothing in Fedora depends. (We keep a list of those at [1].)
I'm +1 to the idea of dropping Python 2 support in general, but I'm not sure we should really do it gradually (which is what would effectively happen if some packagers start dropping now and others later, and others not at all). It seems to me like it'd be cleaner to have a release note on Fedora 30 that's just "Python 2 support dropped" and do it all at once. Thoughts?
On Fri, 23 Mar 2018 12:57:19 -0400, you wrote:
On 03/23/2018 07:23 AM, Petr Viktorin wrote:
In case no one steps up, we'd like to start dropping Python 2 support from dependent packages *now*, starting with ported libraries on whose python2 version nothing in Fedora depends. (We keep a list of those at [1].)
I'm +1 to the idea of dropping Python 2 support in general, but I'm not sure we should really do it gradually (which is what would effectively happen if some packagers start dropping now and others later, and others not at all). It seems to me like it'd be cleaner to have a release note on Fedora 30 that's just "Python 2 support dropped" and do it all at once. Thoughts?
It's not just all the Python 2 code that is packaged in Fedora though, but also all the Python 2 code people are running on their machines.
By gradually (or sooner than Fedora 30) getting rid of all the libraries and other Python 2 stuff it at least gives the option for those people who get surprised to fix things before the Python interpreter itself goes EOL and doesn't get security fixes.
Petr Viktorin wrote:
As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
IMHO, this is clearly the right thing to do. I have been doing security backports for qt3 and kdelibs3 for years, and now also qt 4 and kdelibs 4. It is not an unreasonable amount of work, though to be very clear I will NOT be the one to do this for Python 2, somebody experienced with and interested in Python should do it.
Especially for the first couple years, it will be possible to just borrow fixes from other distros, in particular RHEL/CentOS. As was pointed out elsewhere in this thread, EL7 ships Python 2.7 and should be supported until 2024. (That said, RHEL typically only fixes the really critical issues. My experience with qt3 and kdelibs3 is that RHEL was not always proactive in backporting security fixes and sometimes even ended up picking up my Fedora fix, weeks later. But there are also other distros around.)
Kevin Kofler
On 03/24/18 15:28, Kevin Kofler wrote:
Petr Viktorin wrote:
As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
IMHO, this is clearly the right thing to do. I have been doing security backports for qt3 and kdelibs3 for years, and now also qt 4 and kdelibs 4. It is not an unreasonable amount of work, though to be very clear I will NOT be the one to do this for Python 2, somebody experienced with and interested in Python should do it.
And if you read the original mail to the end, you'll find that our position is not as black-and-white as it might look from the Subject line. As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* – but just for developers who need to test backwards compatibility of their upstream libraries; we don't want to see them used as a base for Fedora packages. Why? To make sure Fedora packages work with modern Python, and to have only one time-sensitive place to concentrate on when a critical security fix comes. We want to put Python 2.7 in the same situation.
Part of the reason to start dropping Python 2 packages now is to figure out which packages can do it now and which ones will need additional help or coordination in the next few years.
As I wrote in the beginning of the e-mail, we'd rather go out and change the packaging guidelines to say "please drop your unneeded python2 subpackages, or let us drop them for you". (Note the word *unneeded*.) That would make a nice a simple message, and in effect it would give you the same options you have now. But it turns out we can't say just that (for good reasons [0]), so we're explicitly mentioning your second option – "if you can manage the transition better, come and do it instead of us". I doubt anyone can – Python SIG is, by definition, the people experienced with and interested in packaging Python in Fedora. And yes, we'll do our best to manage things, with cooperation with interested packagers.
There's of course a third option – if you don't want to take over *everything* but have ideas about how to do something better – respecting that if you're asking someone to do more work, they might (or might not) say no – then come over to Python SIG [1] and talk!
And let me mention this one explicitly: expecting us to maintain Python 2 *is* implicitly asking us to do work. It's not necessarily bad per se, but don't complain if we ask you to do some work in return. We'll be glad to help anyone who respects that.
[0] https://pagure.io/packaging-committee/issue/753 [1] https://fedoraproject.org/wiki/SIGs/Python
Especially for the first couple years, it will be possible to just borrow fixes from other distros, in particular RHEL/CentOS. As was pointed out elsewhere in this thread, EL7 ships Python 2.7 and should be supported until 2024. (That said, RHEL typically only fixes the really critical issues. My experience with qt3 and kdelibs3 is that RHEL was not always proactive in backporting security fixes and sometimes even ended up picking up my Fedora fix, weeks later. But there are also other distros around.)
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Mon, 26 Mar 2018, 10:59 Petr Viktorin, pviktori@redhat.com wrote:
On 03/24/18 15:28, Kevin Kofler wrote:
Petr Viktorin wrote:
As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
IMHO, this is clearly the right thing to do. I have been doing security backports for qt3 and kdelibs3 for years, and now also qt 4 and kdelibs
It is not an unreasonable amount of work, though to be very clear I will
NOT
be the one to do this for Python 2, somebody experienced with and
interested
in Python should do it.
And if you read the original mail to the end, you'll find that our position is not as black-and-white as it might look from the Subject line. As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* – but just for developers who need to test backwards compatibility of their upstream libraries; we don't want to see them used as a base for Fedora packages. Why? To make sure Fedora packages work with modern Python, and to have only one time-sensitive place to concentrate on when a critical security fix comes. We want to put Python 2.7 in the same situation.
Part of the reason to start dropping Python 2 packages now is to figure out which packages can do it now and which ones will need additional help or coordination in the next few years.
As I wrote in the beginning of the e-mail, we'd rather go out and change the packaging guidelines to say "please drop your unneeded python2 subpackages, or let us drop them for you". (Note the word *unneeded*.) That would make a nice a simple message, and in effect it would give you the same options you have now. But it turns out we can't say just that (for good reasons [0]), so we're explicitly mentioning your second option – "if you can manage the transition better, come and do it instead of us". I doubt anyone can – Python SIG is, by definition, the people experienced with and interested in packaging Python in Fedora. And yes, we'll do our best to manage things, with cooperation with interested packagers.
There's of course a third option – if you don't want to take over *everything* but have ideas about how to do something better – respecting that if you're asking someone to do more work, they might (or might not) say no – then come over to Python SIG [1] and talk!
And let me mention this one explicitly: expecting us to maintain Python 2 *is* implicitly asking us to do work. It's not necessarily bad per se, but don't complain if we ask you to do some work in return. We'll be glad to help anyone who respects that.
[0] https://pagure.io/packaging-committee/issue/753 [1] https://fedoraproject.org/wiki/SIGs/Python
Especially for the first couple years, it will be possible to just borrow fixes from other distros, in particular RHEL/CentOS. As was pointed out elsewhere in this thread, EL7 ships Python 2.7 and should be supported
until
- (That said, RHEL typically only fixes the really critical issues.
My
experience with qt3 and kdelibs3 is that RHEL was not always proactive in backporting security fixes and sometimes even ended up picking up my
Fedora
fix, weeks later. But there are also other distros around.)
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course ansible isn't switching to py3 for the controller (and therefore local) until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it work.
Worse is if you bump into a module not ported yet and then you have a split of python versions and playbooks required.
Naturally there's no technical reason to drop the library in F28 and there's no Change filed for it.
We at least need a "common bugs" with all the python2-* libraries being dropped in F28 and really they shouldn't be going without a Change.
For a "soft despondency" like firewalld I'd argue that it shouldn't drop until F29 when ansible goes py3 by default (it has a Change filed to that effect).
To be clear I'm 100% comfortable with python2 being dropped in the proposed timescale... but let's do it sensibly and not have it surprise people.
On 04/04/2018 09:21 AM, James Hogarth wrote:
...snip...
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course ansible isn't switching to py3 for the controller (and therefore local) until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it work.
Yeah, you would need to set ansible_python_interpreter for localhost, which you could add to your command line with -e... -e 'ansible_python_interpreter=/usr/bin/python3'
Worse is if you bump into a module not ported yet and then you have a split of python versions and playbooks required.
Yeah, thats bad, but if there's things that are only python2 as of now, really the ansible module/you should switch them to some python3 alternative.
Naturally there's no technical reason to drop the library in F28 and there's no Change filed for it.
Yeah, I guess the only alternative though would be to try dropping them all at once. :(
We at least need a "common bugs" with all the python2-* libraries being dropped in F28 and really they shouldn't be going without a Change.
For a "soft despondency" like firewalld I'd argue that it shouldn't drop until F29 when ansible goes py3 by default (it has a Change filed to that effect).
Well, yes, but that doesn't really tell the entire story, because thats just the control host. You can continue to use python2 on targets.
To be clear I'm 100% comfortable with python2 being dropped in the proposed timescale... but let's do it sensibly and not have it surprise people.
Yeah, a list/release note would be indeed welcome...
kevin
On 04/04/2018 10:46 AM, Kevin Fenzi wrote:
On 04/04/2018 09:21 AM, James Hogarth wrote:
...snip...
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course ansible isn't switching to py3 for the controller (and therefore local) until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it work.
Yeah, you would need to set ansible_python_interpreter for localhost, which you could add to your command line with -e... -e 'ansible_python_interpreter=/usr/bin/python3'
Or, actually:
yum install ansible-python3 python-firewall ansible localhost -m firewalld
(since ansible-python3 defaults to python3 for the control host/localhost)
kevin
On Wed, 2018-04-04 at 10:51 -0700, Kevin Fenzi wrote:
On 04/04/2018 10:46 AM, Kevin Fenzi wrote:
On 04/04/2018 09:21 AM, James Hogarth wrote:
...snip...
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course ansible isn't switching to py3 for the controller (and therefore local) until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it work.
Yeah, you would need to set ansible_python_interpreter for localhost, which you could add to your command line with -e... -e 'ansible_python_interpreter=/usr/bin/python3'
Or, actually:
yum install ansible-python3 python-firewall ansible localhost -m firewalld
(since ansible-python3 defaults to python3 for the control host/localhost)
This rather begs the question of whether there are any modules which only work *with python 2*, though...
On Wed, 4 Apr 2018, 21:28 Adam Williamson, adamwill@fedoraproject.org wrote:
On Wed, 2018-04-04 at 10:51 -0700, Kevin Fenzi wrote:
On 04/04/2018 10:46 AM, Kevin Fenzi wrote:
On 04/04/2018 09:21 AM, James Hogarth wrote:
...snip...
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of
course
ansible isn't switching to py3 for the controller (and therefore
local)
until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it
work.
Yeah, you would need to set ansible_python_interpreter for localhost, which you could add to your command line with -e... -e 'ansible_python_interpreter=/usr/bin/python3'
Or, actually:
yum install ansible-python3 python-firewall ansible localhost -m firewalld
(since ansible-python3 defaults to python3 for the control
host/localhost)
This rather begs the question of whether there are any modules which only work *with python 2*, though... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
The ansible guys might know... or might not really tbh which is why the current documentation upstream still declares it a technology preview.
The test coverage is growing there but not massively comprehensive... and tbh I expect the greater problem will be random galaxy stuff or local plugins and modules people have written.
It's going to be a very disruptive change in F29 as it is... to the extent I might start directing people to use the upstream ansible repos directly if they don't change there.
I'm honestly looking to the py2 drop in F30 as a necessary evil but one I'm looking at with intense trepidation.
On 04/04/2018 01:35 PM, James Hogarth wrote:
On Wed, 4 Apr 2018, 21:28 Adam Williamson, adamwill@fedoraproject.org wrote:
This rather begs the question of whether there are any modules which only work *with python 2*, though...
The answer is (at least based on what I know from talking with upstream) that ansible has been pretty well tested with python3 for the controller host. All upstream PR's are tested against both python2 and python3. All upstream CI runs against python2 and python3.
For the target/managed node side: all core modules have been tested under python3. Community supported modules however they have been fixing python3 issues as they come up. There's not any full testing thats happened over all those, nor is there likely to be.
Heres the list of known python3 bugs in modules: https://github.com/ansible/ansible/issues?utf8=%E2%9C%93&q=is%3Aissue+is...
The ansible guys might know... or might not really tbh which is why the current documentation upstream still declares it a technology preview.
The test coverage is growing there but not massively comprehensive... and tbh I expect the greater problem will be random galaxy stuff or local plugins and modules people have written.
Right.
However, they do say that most problems are trivial to fix up also.
It's going to be a very disruptive change in F29 as it is... to the extent I might start directing people to use the upstream ansible repos directly if they don't change there.> I'm honestly looking to the py2 drop in F30 as a necessary evil but one I'm looking at with intense trepidation.
Well, if it happens... some people might choose to keep it alive.
kevin
On 4 April 2018 at 22:06, Kevin Fenzi kevin@scrye.com wrote:
On 04/04/2018 01:35 PM, James Hogarth wrote:
On Wed, 4 Apr 2018, 21:28 Adam Williamson, adamwill@fedoraproject.org wrote:
This rather begs the question of whether there are any modules which only work *with python 2*, though...
The answer is (at least based on what I know from talking with upstream) that ansible has been pretty well tested with python3 for the controller host. All upstream PR's are tested against both python2 and python3. All upstream CI runs against python2 and python3.
For the target/managed node side: all core modules have been tested under python3. Community supported modules however they have been fixing python3 issues as they come up. There's not any full testing thats happened over all those, nor is there likely to be.
Heres the list of known python3 bugs in modules: https://github.com/ansible/ansible/issues?utf8=%E2%9C%93&q=is%3Aissue+is...
Yup this is why I'm very nervous about the F29/F30 plans in the face of this ...
The ansible guys might know... or might not really tbh which is why the current documentation upstream still declares it a technology preview.
The test coverage is growing there but not massively comprehensive... and tbh I expect the greater problem will be random galaxy stuff or local plugins and modules people have written.
Right.
However, they do say that most problems are trivial to fix up also.
Trivial ... but still need time and people to review, merge and then release them.
Stuff in galaxy can be fixed relatively quickly by owners as it bypasses github stuff of course ... but modules shipped with ansible already will take a while to go from PR to a built and shipped release.
It's going to be a very disruptive change in F29 as it is... to the extent I might start directing people to use the upstream ansible repos directly if they don't change there.> I'm honestly looking to the py2 drop in F30 as a necessary evil but one I'm looking at with intense trepidation.
Well, if it happens... some people might choose to keep it alive.
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Well ... even if they do that doesn't help if a bunch of packages (especially pretty core ones to Fedora like firewalld) drop their python2 libraries ...
Adam Williamson (adamwill@fedoraproject.org) said:
This rather begs the question of whether there are any modules which only work *with python 2*, though...
Given 1500+ modules, all of which can have their own python library dependencies, the safe answer is 'yes'.
We're working to solve that, but it's a proces...
Bill
On Wed, 4 Apr 2018, 18:52 Kevin Fenzi, kevin@scrye.com wrote:
On 04/04/2018 10:46 AM, Kevin Fenzi wrote:
On 04/04/2018 09:21 AM, James Hogarth wrote:
...snip...
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course ansible isn't switching to py3 for the controller (and therefore local) until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it work.
Yeah, you would need to set ansible_python_interpreter for localhost, which you could add to your command line with -e... -e 'ansible_python_interpreter=/usr/bin/python3'
Or, actually:
yum install ansible-python3 python-firewall ansible localhost -m firewalld
(since ansible-python3 defaults to python3 for the control host/localhost)
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
You're right that solves the issue for the control host, assuming everything else you are doing on there is fine with py3, but doesn't solve F28 target systems.
It is also unexpected and not in and changes notes or common issues (yet) ...
What happens to systems that currently have the library during an upgrade?
It was just dropped from the spec (As many will be) rather than formally retired so it's not added to the "this is dead" super obsoleting package.
Even if we don't get a change per library (which I agree would be too much) can we please get something clear for the F28 (and later F29) release ... we should be able to quickly generate it with dnf list
On 04/04/18 18:21, James Hogarth wrote: [...]
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course ansible isn't switching to py3 for the controller (and therefore local) until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it work.
Worse is if you bump into a module not ported yet and then you have a split of python versions and playbooks required.
Is there some list of packages Ansible depends on? I'd can to add the list to portingdb, so we could warn people about the implications of dropping subpackages. Currently we use RPM deps, so the needs of Ansible clients are invisible.
Naturally there's no technical reason to drop the library in F28 and there's no Change filed for it.
It's the maintainer's decision, as with any RPM. Has anyone communicated to the firewalld maintainer that Ansible depends on the package? Again, a maintainer can't very well notice a "soft dependency", unless they use Ansible themselves.
We at least need a "common bugs" with all the python2-* libraries being dropped in F28 and really they shouldn't be going without a Change.
For a "soft despondency" like firewalld I'd argue that it shouldn't drop
until F29 when ansible goes py3 by default (it has a Change filed to that effect).
To be clear I'm 100% comfortable with python2 being dropped in the proposed timescale... but let's do it sensibly and not have it surprise people.
On 6 April 2018 at 10:18, Petr Viktorin pviktori@redhat.com wrote:
On 04/04/18 18:21, James Hogarth wrote: [...]
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course ansible isn't switching to py3 for the controller (and therefore local) until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it work.
Worse is if you bump into a module not ported yet and then you have a split of python versions and playbooks required.
Is there some list of packages Ansible depends on? I'd can to add the list to portingdb, so we could warn people about the implications of dropping subpackages. Currently we use RPM deps, so the needs of Ansible clients are invisible.
It's not even as simple as that ... as Bill Nottingham mentioned the bigger problem is going to the be the thousands of libraries and plugins on eg ansible galaxy out there ...
It's just going to be a huge (but required, just we need to be careful on communication so as not to tarnish our image ... especially with a core Red Hat technology like ansible) disruption.
Naturally there's no technical reason to drop the library in F28 and there's no Change filed for it.
It's the maintainer's decision, as with any RPM. Has anyone communicated to the firewalld maintainer that Ansible depends on the package? Again, a maintainer can't very well notice a "soft dependency", unless they use Ansible themselves.
Right ... but that's why we have the Change process - so stuff like this can get noticed in good time and those who are aware of soft dependencies can speak up.
There's a good reason we have the change deadlines we do - and honestly I think dropping a subpackage (as opposed to retiring which is more visible) is sufficiently disruptive (and annoyingly invisible otherwise) that it should go through the Change process.
It's also bigger than firewalld - that's just the one that bit me the other day when trying to do owncloud testing.
Do note that, despite my dislike for dropping the subpackage without an announced Change, the biggest issue I see here is the sheer lack of communication with out userbase with what is going on.
----- Original Message -----
From: "James Hogarth" james.hogarth@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Friday, April 6, 2018 12:09:10 PM Subject: Re: Intent to orphan Python 2
On 6 April 2018 at 10:18, Petr Viktorin pviktori@redhat.com wrote:
On 04/04/18 18:21, James Hogarth wrote: [...]
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course ansible isn't switching to py3 for the controller (and therefore local) until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it work.
Worse is if you bump into a module not ported yet and then you have a split of python versions and playbooks required.
Is there some list of packages Ansible depends on? I'd can to add the list to portingdb, so we could warn people about the implications of dropping subpackages. Currently we use RPM deps, so the needs of Ansible clients are invisible.
It's not even as simple as that ... as Bill Nottingham mentioned the bigger problem is going to the be the thousands of libraries and plugins on eg ansible galaxy out there ...
It's just going to be a huge (but required, just we need to be careful on communication so as not to tarnish our image ... especially with a core Red Hat technology like ansible) disruption.
Naturally there's no technical reason to drop the library in F28 and there's no Change filed for it.
It's the maintainer's decision, as with any RPM. Has anyone communicated to the firewalld maintainer that Ansible depends on the package? Again, a maintainer can't very well notice a "soft dependency", unless they use Ansible themselves.
Right ... but that's why we have the Change process - so stuff like this can get noticed in good time and those who are aware of soft dependencies can speak up.
AFAIK there is no guideline for making the packagers responsible for soft dependencies, or anything guiding how to check for those.
If anything, the people who care about that should draft something to avoid those nuisances.
Again if someone sees their package as leaves within the distribution, how could he be aware of anything requiring it outside the rpm level? At this point I don't think anyone would even think of the change process for packages that on the surface nothing depends on.
There's a good reason we have the change deadlines we do - and honestly I think dropping a subpackage (as opposed to retiring which is more visible) is sufficiently disruptive (and annoyingly invisible otherwise) that it should go through the Change process.
It's also bigger than firewalld - that's just the one that bit me the other day when trying to do owncloud testing.
Do note that, despite my dislike for dropping the subpackage without an announced Change, the biggest issue I see here is the sheer lack of communication with out userbase with what is going on. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Fri, 2018-04-06 at 11:09 +0100, James Hogarth wrote:
There's a good reason we have the change deadlines we do - and honestly I think dropping a subpackage (as opposed to retiring which is more visible) is sufficiently disruptive (and annoyingly invisible otherwise) that it should go through the Change process.
It wouldn't be remotely viable to have a Change for every dropped subpackage. It'd completely overwhelm the process.
On Fri, Apr 06, 2018 at 11:18:13AM +0200, Petr Viktorin wrote:
On 04/04/18 18:21, James Hogarth wrote: [...]
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course ansible isn't switching to py3 for the controller (and therefore local) until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it work.
Worse is if you bump into a module not ported yet and then you have a split of python versions and playbooks required.
Is there some list of packages Ansible depends on? I'd can to add the list to portingdb, so we could warn people about the implications of dropping subpackages. Currently we use RPM deps, so the needs of Ansible clients are invisible.
Naturally there's no technical reason to drop the library in F28 and there's no Change filed for it.
It's the maintainer's decision, as with any RPM. Has anyone communicated to the firewalld maintainer that Ansible depends on the package? Again, a maintainer can't very well notice a "soft dependency", unless they use Ansible themselves.
I think it's just something that a maintainer should know — how users actually use the package they are maintaining. Removing a python subpackage should be handled similarly to any other removal, for example of an executable or certain functionality from an executable. Get a rough idea of what will be impacted, and reach out to users about the change.
https://codesearch.debian.net/search?q=import+firewall immediately gives a list of packages that should be checked. I don't have an inkling where python-firewall would be used, but for packages that I maintain, I have at least a general idea, and then it's much easier to search.
Zbyszek
On 04/06/2018 02:18 AM, Petr Viktorin wrote:
Is there some list of packages Ansible depends on?
Nope. I don't think there could be either. (Or at least not a very good one).
You could possibly scrape the core modules shipped with ansible, but thats going to give you tons of things that aren't even in Fedora or are free software, and we cannot know what custom modules many people have written or what they depend on.
kevin
On Mon, Mar 26, 2018 at 11:58:57AM +0200, Petr Viktorin wrote:
And if you read the original mail to the end, you'll find that our position is not as black-and-white as it might look from the Subject line. As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* – but just for developers who need to test backwards compatibility of their upstream libraries; we don't want to see them used as a base for Fedora packages. Why? To make sure Fedora packages work with modern Python, and to have only one time-sensitive place to concentrate on when a critical security fix comes. We want to put Python 2.7 in the same situation.
Sorry I'm a late to this thread. Have you considered making the "legacy" python 2.7 a module? This would provide a clear way to define the lifecycle and service level expectations.
On 5 April 2018 at 13:23, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Mar 26, 2018 at 11:58:57AM +0200, Petr Viktorin wrote:
And if you read the original mail to the end, you'll find that our position is not as black-and-white as it might look from the Subject line. As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* – but just for developers who need to test backwards compatibility of their upstream libraries; we don't want to see them used as a base for Fedora packages. Why? To make sure Fedora packages work with modern Python, and to have only one time-sensitive place to concentrate on when a critical security fix comes. We want to put Python 2.7 in the same situation.
Sorry I'm a late to this thread. Have you considered making the "legacy" python 2.7 a module? This would provide a clear way to define the lifecycle and service level expectations.
But it's not python2 itself going that is really the painful part of this ... it's the various python2-* packages going bye-bye as maintainers (are already) dropping them... even when they still work.
Having a module of python2 does nothing at all to solve the actual bit of pain we are already facing.
On Thu, Apr 05, 2018 at 03:11:47PM +0100, James Hogarth wrote:
But it's not python2 itself going that is really the painful part of this ... it's the various python2-* packages going bye-bye as maintainers (are already) dropping them... even when they still work.
Having a module of python2 does nothing at all to solve the actual bit of pain we are already facing.
I'm imagining all those dependent packages _also_ moving to that module....
On Thu, 5 Apr 2018, 16:05 Matthew Miller, mattdm@fedoraproject.org wrote:
On Thu, Apr 05, 2018 at 03:11:47PM +0100, James Hogarth wrote:
But it's not python2 itself going that is really the painful part of this ... it's the various python2-* packages going bye-bye as maintainers (are already) dropping them... even when they still work.
Having a module of python2 does nothing at all to solve the actual bit of pain we are already facing.
I'm imagining all those dependent packages _also_ moving to that module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL of 2020 when there is no extra effort to include the subpackage in their "normal" koiji+bodhi workflow for the main repos... why would they go to the extra effort of a special split to do that (no longer simple subpackage) into a module?
On Thu, Apr 05, 2018 at 04:03:24PM +0000, James Hogarth wrote:
I'm imagining all those dependent packages _also_ moving to that module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL of 2020 when there is no extra effort to include the subpackage in their "normal" koiji+bodhi workflow for the main repos... why would they go to the extra effort of a special split to do that (no longer simple subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be quite a pain for packages where python 2 bindings are subpackages.
On Thu, 5 Apr 2018, 18:28 Matthew Miller, mattdm@fedoraproject.org wrote:
On Thu, Apr 05, 2018 at 04:03:24PM +0000, James Hogarth wrote:
I'm imagining all those dependent packages _also_ moving to that module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed
EOL
of 2020 when there is no extra effort to include the subpackage in their "normal" koiji+bodhi workflow for the main repos... why would they go to the extra effort of a special split to do that (no longer simple subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be quite a pain for packages where python 2 bindings are subpackages.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Heh just saw this one from a comment on Reddit...
https://bugs.launchpad.net/calibre/+bug/1714107
Unless Nirik does a "maintainer patch" porting the entire code over himself I guess no more Calibre in F30 ;)
On Thu, Apr 5, 2018 at 9:06 PM, James Hogarth james.hogarth@gmail.com wrote:
On Thu, 5 Apr 2018, 18:28 Matthew Miller, mattdm@fedoraproject.org wrote:
On Thu, Apr 05, 2018 at 04:03:24PM +0000, James Hogarth wrote:
I'm imagining all those dependent packages _also_ moving to that module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL of 2020 when there is no extra effort to include the subpackage in their "normal" koiji+bodhi workflow for the main repos... why would they go to the extra effort of a special split to do that (no longer simple subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be quite a pain for packages where python 2 bindings are subpackages.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Heh just saw this one from a comment on Reddit...
https://bugs.launchpad.net/calibre/+bug/1714107
Unless Nirik does a "maintainer patch" porting the entire code over himself I guess no more Calibre in F30 ;)
"I am perfectly capable of maintaining python 2 myself." Best laugh I had today.
But that's beside the point. I just wanted to throw in something that I don't quite understand about this thread:
If I understand correctly, the original proposal was about - dropping python2 support and sub-packages only in "fedora > 29" or "fedora >= 29" (see the original mail in this thread), - starting from leaf packages, so no unmet dependencies are introduced during the retirement process.
According to this, the python2 bindings for firewalld shouldn't have been dropped from f28 at all, because - there's still something depending on them (ansible support for firewalld, still uses python2 on f28), and - the change was explicitly about f29+ (and not f28, too).
Please correct me if I am wrong.
If I am correct though, it looks like the rawhide change to remove the python2 sub-package from firewalld was mistakenly merged from rawhide into f28, and should be reverted.
Fabio
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Thu, Apr 05, 2018 at 10:53:03PM +0200, Fabio Valentini wrote:
On Thu, Apr 5, 2018 at 9:06 PM, James Hogarth james.hogarth@gmail.com wrote:
On Thu, 5 Apr 2018, 18:28 Matthew Miller, mattdm@fedoraproject.org wrote:
On Thu, Apr 05, 2018 at 04:03:24PM +0000, James Hogarth wrote:
I'm imagining all those dependent packages _also_ moving to that module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL of 2020 when there is no extra effort to include the subpackage in their "normal" koiji+bodhi workflow for the main repos... why would they go to the extra effort of a special split to do that (no longer simple subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be quite a pain for packages where python 2 bindings are subpackages.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Heh just saw this one from a comment on Reddit...
https://bugs.launchpad.net/calibre/+bug/1714107
Unless Nirik does a "maintainer patch" porting the entire code over himself I guess no more Calibre in F30 ;)
"I am perfectly capable of maintaining python 2 myself." Best laugh I had today.
But that's beside the point. I just wanted to throw in something that I don't quite understand about this thread:
If I understand correctly, the original proposal was about
- dropping python2 support and sub-packages only in "fedora > 29" or
"fedora >= 29" (see the original mail in this thread),
- starting from leaf packages, so no unmet dependencies are introduced
during the retirement process.
According to this, the python2 bindings for firewalld shouldn't have been dropped from f28 at all, because
- there's still something depending on them (ansible support for
firewalld, still uses python2 on f28), and
This dependency is not visible via rpm, because it's on the remote side not the controller side where Ansible is installed. i.e.
$ repoquery --whatrequires python2-firewall
yields nothing. As such, I missed this indirect dependency. It would be nice if there was a way to express this.
Correct me if I'm wrong, but won't this be a nuisance in Ansible for some time? If the controller side (regardless of distro) defaults to invoking python2 on the remote then it will fail on f29+. I guess Ansible has knobs to tell it to use python3 on a set of remotes. Alternatively you can install python3-ansible.
My point is, restoring the python2-firewall subpackage for f28 will help targets that are f28. But in f29, the package will definitely be gone and we're still "broken" for many controlling distros including older Fedora releases.
- the change was explicitly about f29+ (and not f28, too).
I had dropped the python2-firewall subpackage before this thread was started.
Please correct me if I am wrong.
If I am correct though, it looks like the rawhide change to remove the python2 sub-package from firewalld was mistakenly merged from rawhide into f28, and should be reverted.
I'm not an Ansible user so I don't know how painful it is for the python2-firewall subpackage to be gone. If the majority thinks it should be restored, then we'll bring it back.
On 6 April 2018 at 01:10, Eric Garver egarver@redhat.com wrote:
On Thu, Apr 05, 2018 at 10:53:03PM +0200, Fabio Valentini wrote:
On Thu, Apr 5, 2018 at 9:06 PM, James Hogarth james.hogarth@gmail.com wrote:
On Thu, 5 Apr 2018, 18:28 Matthew Miller, mattdm@fedoraproject.org wrote:
On Thu, Apr 05, 2018 at 04:03:24PM +0000, James Hogarth wrote:
I'm imagining all those dependent packages _also_ moving to that module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL of 2020 when there is no extra effort to include the subpackage in their "normal" koiji+bodhi workflow for the main repos... why would they go to the extra effort of a special split to do that (no longer simple subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be quite a pain for packages where python 2 bindings are subpackages.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Heh just saw this one from a comment on Reddit...
https://bugs.launchpad.net/calibre/+bug/1714107
Unless Nirik does a "maintainer patch" porting the entire code over himself I guess no more Calibre in F30 ;)
"I am perfectly capable of maintaining python 2 myself." Best laugh I had today.
But that's beside the point. I just wanted to throw in something that I don't quite understand about this thread:
If I understand correctly, the original proposal was about
- dropping python2 support and sub-packages only in "fedora > 29" or
"fedora >= 29" (see the original mail in this thread),
- starting from leaf packages, so no unmet dependencies are introduced
during the retirement process.
According to this, the python2 bindings for firewalld shouldn't have been dropped from f28 at all, because
- there's still something depending on them (ansible support for
firewalld, still uses python2 on f28), and
This dependency is not visible via rpm, because it's on the remote side not the controller side where Ansible is installed. i.e.
$ repoquery --whatrequires python2-firewall
yields nothing. As such, I missed this indirect dependency. It would be nice if there was a way to express this.
Correct me if I'm wrong, but won't this be a nuisance in Ansible for some time? If the controller side (regardless of distro) defaults to invoking python2 on the remote then it will fail on f29+. I guess Ansible has knobs to tell it to use python3 on a set of remotes. Alternatively you can install python3-ansible.
My point is, restoring the python2-firewall subpackage for f28 will help targets that are f28. But in f29, the package will definitely be gone and we're still "broken" for many controlling distros including older Fedora releases.
- the change was explicitly about f29+ (and not f28, too).
I had dropped the python2-firewall subpackage before this thread was started.
Please correct me if I am wrong.
If I am correct though, it looks like the rawhide change to remove the python2 sub-package from firewalld was mistakenly merged from rawhide into f28, and should be reverted.
I'm not an Ansible user so I don't know how painful it is for the python2-firewall subpackage to be gone. If the majority thinks it should be restored, then we'll bring it back.
Just align the drop to F29, at the earliest, to align with ansible itself changing ... and let's get a Change listed (or ask the ansible team to note this on their change) so that at least there's documentation ...
The only real problem right now is a lack of communication in python2-* drops ... we just need to be a lot clearer there.
Note the latest ansible documentation actually states:
Requires the python2 bindings of firewalld, which may not be installed by default if the distribution switched to python 3
Also there is a PyPi package for firewall that is completely different from this making things even messier as if firewalld drops the subpackage there is no way for someone to get a py2 firewalld library on the target system in the event their ansible module doesn't work with py3
This is going to be a very messy couple of Fedora releases I fear ...
On 04/05/2018 05:10 PM, Eric Garver wrote:
...snip...
Correct me if I'm wrong, but won't this be a nuisance in Ansible for some time? If the controller side (regardless of distro) defaults to invoking python2 on the remote then it will fail on f29+. I guess Ansible has knobs to tell it to use python3 on a set of remotes.
Yes, you can set a variable to tell ansible what the path is to the python you want to use on the target. So, for newer fedora's they should set this likely to python3.
Alternatively you can install python3-ansible.
Well, that will cause the host side to use python3, but not the target.
My point is, restoring the python2-firewall subpackage for f28 will help targets that are f28. But in f29, the package will definitely be gone and we're still "broken" for many controlling distros including older Fedora releases.
Yeah, there isn't an easy answer here. I suppose we could change the default target ansible to python3 in f29+, that would help Fedora installs, but then mixed installs would have to change say RHEL7 targets to use python2, so it becomes a mix... we don't know what the mix of hosts people target are.
I'm not an Ansible user so I don't know how painful it is for the python2-firewall subpackage to be gone. If the majority thinks it should be restored, then we'll bring it back.
IMHO, people can just set the target host(s) to use python3 now, as they are going to have to do this sooner or later.
kevin
----- Original Message -----
From: "Fabio Valentini" decathorpe@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Thursday, April 5, 2018 10:53:03 PM Subject: Re: Intent to orphan Python 2
On Thu, Apr 5, 2018 at 9:06 PM, James Hogarth james.hogarth@gmail.com wrote:
On Thu, 5 Apr 2018, 18:28 Matthew Miller, mattdm@fedoraproject.org wrote:
On Thu, Apr 05, 2018 at 04:03:24PM +0000, James Hogarth wrote:
I'm imagining all those dependent packages _also_ moving to that module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL of 2020 when there is no extra effort to include the subpackage in their "normal" koiji+bodhi workflow for the main repos... why would they go to the extra effort of a special split to do that (no longer simple subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be quite a pain for packages where python 2 bindings are subpackages.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Heh just saw this one from a comment on Reddit...
https://bugs.launchpad.net/calibre/+bug/1714107
Unless Nirik does a "maintainer patch" porting the entire code over himself I guess no more Calibre in F30 ;)
"I am perfectly capable of maintaining python 2 myself." Best laugh I had today.
But that's beside the point. I just wanted to throw in something that I don't quite understand about this thread:
If I understand correctly, the original proposal was about
- dropping python2 support and sub-packages only in "fedora > 29" or
"fedora >= 29" (see the original mail in this thread),
- starting from leaf packages, so no unmet dependencies are introduced
during the retirement process.
According to this, the python2 bindings for firewalld shouldn't have been dropped from f28 at all, because
- there's still something depending on them (ansible support for
firewalld, still uses python2 on f28), and
- the change was explicitly about f29+ (and not f28, too).
Please correct me if I am wrong.
I would say that this is up to the discretion of each individual maintainer.
As packagers tend to check the dependencies on the RPM level and in this case nothing actually required python2-firewalld when querying the repos, how would the packager know that there are somehow other things that depend on it which are not listed anywhere?
On a relevant note, python packaging guidelines are soon subject for a change in regards to that [0]
[0] https://pagure.io/packaging-committee/issue/753
If I am correct though, it looks like the rawhide change to remove the python2 sub-package from firewalld was mistakenly merged from rawhide into f28, and should be reverted.
Fabio
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
"CS" == Charalampos Stratakis cstratak@redhat.com writes:
CS> On a relevant note, python packaging guidelines are soon subject for CS> a change in regards to that [0]
CS> [0] https://pagure.io/packaging-committee/issue/753
Please note that the ticket there started off as a strong discouragement of python2 packaging, but what was actually approved (and hopefully today will be written into the guidelines by me) is simply an extra note that maintainers are not required to package for python2 if they don't want to (which really isn't a change in packaging policy at all). So don't read the ticket title and believe that FPC has approved a blanket ban of python2 subpackages.
To be completely honest, if someone wants to drop a python2 subpackage, that's their prerogative but it does bring up an interesting question. Normally if someone wants to orphan a package, they're welcome to do so and others are welcome to pick it up. But this is about removing a subpackage. If PackagerA wants to drop python2, but PackagerB wants to volunteer to maintain it, the only options I see are:
* PackagerB offers to co-maintain the package, which will result in PackagerA having to deal with the python2 subpackage anyway.
* The python2 subpackage gets generated by a separate python2-foo source RPM that PackagerB maintains, and the original source package becomes completely free of python2 stuff.
It may be useful to see if FPC will approve a blanket exception to the review process for splitting python2-* source packages out of python-* source packages, so that bit of bureaucracy can be skipped.
- J<
On Fri, Apr 06, 2018 at 10:33:04AM -0500, Jason L Tibbitts III wrote:
To be completely honest, if someone wants to drop a python2 subpackage, that's their prerogative but it does bring up an interesting question. Normally if someone wants to orphan a package, they're welcome to do so and others are welcome to pick it up. But this is about removing a subpackage.
Yes, but as with any removal action, it behooves the maintainer to query and think if that removal will not cause disruption, and if it will, what is the best way to proceed (announce more widely, warn and delay the removal, postpone indefinitely?).
If PackagerA wants to drop python2, but PackagerB wants to volunteer to maintain it, the only options I see are:
- The python2 subpackage gets generated by a separate python2-foo source RPM that PackagerB maintains, and the original source package becomes completely free of python2 stuff.
It may be useful to see if FPC will approve a blanket exception to the review process for splitting python2-* source packages out of python-* source packages, so that bit of bureaucracy can be skipped.
Please don't. This is a repeat of the original idea of having separate python3 packages back when python3 was being introduced. This was always a huge pain and waste of maintainer time. From my perspective the idea of separate python3 source packages held back the support for python3 in Fedora by a year or two.
Doing this on any massive scale would means hundreds (up to 2800?) "new" packages, a way to burn massive amounts of maintainer time.
- PackagerB offers to co-maintain the package, which will result in PackagerA having to deal with the python2 subpackage anyway.
Let's do this instead. We need more co-maintainership and more co-operation in Fedora. If there are people who want or need to support the python2 version, I'm sure we can have informal agreements where the bugs with python2 get assigned to them. Keeping an exisiting python2 subpackage is really no big deal.
Zbyszek
On 7.4.2018 15:53, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 06, 2018 at 10:33:04AM -0500, Jason L Tibbitts III wrote:
To be completely honest, if someone wants to drop a python2 subpackage, that's their prerogative but it does bring up an interesting question. Normally if someone wants to orphan a package, they're welcome to do so and others are welcome to pick it up. But this is about removing a subpackage.
Yes, but as with any removal action, it behooves the maintainer to query and think if that removal will not cause disruption, and if it will, what is the best way to proceed (announce more widely, warn and delay the removal, postpone indefinitely?).
So apparently the general confusion/problem here is lack of communication when removing python2-subpackages.
Filling a Fedora Change proposal for every single python2 subpackage removal feels a bit overengineered. So let's set up some basic rules about what to do when a python2 subpackage is being removed. E.g. do it in rawhide only, send an announcement do devel, wait X days, etc.
On Sat, Apr 07, 2018 at 04:15:15PM +0200, Miro Hrončok wrote:
On 7.4.2018 15:53, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 06, 2018 at 10:33:04AM -0500, Jason L Tibbitts III wrote:
To be completely honest, if someone wants to drop a python2 subpackage, that's their prerogative but it does bring up an interesting question. Normally if someone wants to orphan a package, they're welcome to do so and others are welcome to pick it up. But this is about removing a subpackage.
Yes, but as with any removal action, it behooves the maintainer to query and think if that removal will not cause disruption, and if it will, what is the best way to proceed (announce more widely, warn and delay the removal, postpone indefinitely?).
So apparently the general confusion/problem here is lack of communication when removing python2-subpackages.
Filling a Fedora Change proposal for every single python2 subpackage removal feels a bit overengineered. So let's set up some basic rules about what to do when a python2 subpackage is being removed. E.g. do it in rawhide only, send an announcement do devel, wait X days, etc.
For timing, I think should piggy-back on the rules for retiring. From user POV, there isn't much difference between a subpackage disappearing and a package being retired. Those rules say [1]:
Do not retire packages in other branches than Branched (until the Final Freeze), Rawhide (master) and EPEL branches (el5, el6, epel7). When you need to add package from EPEL to any RHEL release, only retire EPEL branch when package is released in that RHEL release.
+1 for fedora-devel. A mail to fedora-devel a week in advance should be enough. And if people show up who want to take responsibility for the python2 version, give them ACLs.
[1] https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Zbyszek
Miro Hrončok wrote:
So apparently the general confusion/problem here is lack of communication when removing python2-subpackages.
Filling a Fedora Change proposal for every single python2 subpackage removal feels a bit overengineered. So let's set up some basic rules about what to do when a python2 subpackage is being removed. E.g. do it in rawhide only, send an announcement do devel, wait X days, etc.
How about just NOT removing the subpackage to begin with if there is no strong reason to (such as upstream dropping support)?
It is not even clear at this time that python2 will really end up eradicated and not picked up as e.g. qt3 was. Removing the python2-* subpackages just because they depend on python2 is a very premature move.
Kevin Kofler
On 7.4.2018 18:45, Kevin Kofler wrote> How about just NOT removing the subpackage to begin with if there is no
strong reason to (such as upstream dropping support)?
The strong reason for me as a packager might be "I don't want to maintain this crap anymore, I see no benefit in it."
Strong reasons for the distribution were already discussed above, including:
* we don't have the ability/mapower to remove everything at once * by removing stuff gradually, we have longer time period to fix any issues that it brings
On Sat, 7 Apr 2018, 19:17 Miro Hrončok, mhroncok@redhat.com wrote:
Strong reasons for the distribution were already discussed above, including:
- we don't have the ability/mapower to remove everything at once
Won't it take more total effort to remove things piecemeal rather than all in one go, though?
* by removing stuff gradually, we have longer time period to fix any
issues that it brings
My understanding was that it's now too late to remove things from Fedora 28, and we want Python 2 gone by the time Fedora 30 is released. That only gives us Fedora 29 as wiggle room, which doesn't seem all that gradual to me.
In any case, once we start removing Python 2 components, it seems to me that the message to users is, "Python 2 can't be relied upon in this release". That being the case, if we did go ahead with this staged removal, would it be helpful to think of this change the other way around? Rather than removing Python 2 from Fedora 30 but starting that work during Fedora 29, we're removing it from Fedora 29 but not completing all of that work until Fedora 30?
Peter Oliver wrote:
In any case, once we start removing Python 2 components, it seems to me that the message to users is, "Python 2 can't be relied upon in this release". That being the case, if we did go ahead with this staged removal, would it be helpful to think of this change the other way around? Rather than removing Python 2 from Fedora 30 but starting that work during Fedora 29, we're removing it from Fedora 29 but not completing all of that work until Fedora 30?
Who says Python 2 is going to be removed from Fedora 30 at all? I think this is a completely unrealistic target. Somebody needs to pick it up. It will not be much effort. There will at some point be no new upstream releases, so almost zero packaging work. All that is to do is to pick up the security backports from RHEL/CentOS. I see no benefit from removing the python2 package in such a rush.
Kevin Kofler
On Sun, Apr 8, 2018 at 11:49 AM, Kevin Kofler kevin.kofler@chello.at wrote:
Rex Dieter wrote:
And we've circled back to the original post starting this thread.
Note: intent to *orphan*, not intent to *retire*.
If it is not going to be retired, then why would we want to kill python2-* subpackages throughout the distribution for no reason?
Kevin Kofler
Maintaining code that isn't used means maintaining code you don't test. Discarding support for unused code means that authors of Python modules can test a single set of dependencies.
On 04/08/18 17:49, Kevin Kofler wrote:
Rex Dieter wrote:
And we've circled back to the original post starting this thread.
Note: intent to *orphan*, not intent to *retire*.
If it is not going to be retired, then why would we want to kill python2-* subpackages throughout the distribution for no reason?
By orphaning, I mean:
1. Work with users and maintainers of dependent packages to either remove their dependencies or to share/take over maintainership 2. Drop the package if no one stepped up
This is the first step.
"ZJ" == Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
ZJ> Please don't. This is a repeat of the original idea of having ZJ> separate python3 packages back when python3 was being ZJ> introduced.
It seems that you are suggesting that pointless bureaucracy be kept in place purely because it slows down a process which you don't personally like. If so, that's awfully passive-aggressive.
If someone does wish too create a separate python2 package via a package review, will you also attempt to obstruct that review?
ZJ> This was always a huge pain and waste of maintainer time.
I'm somewhat confused; you seem to wish to make it take more time, not less.
ZJ> Doing this on any massive scale would means hundreds (up to 2800?) ZJ> "new" packages, a way to burn massive amounts of maintainer time.
Has anyone at all suggested doing this on a massive scale? I certainly didn't. I only suggested making it easier to handle the case where a package maintainer simply doesn't want the python2 subpackage to be generated from the main package. I get the impression you took my suggestion and for whatever reason turned it into something else entirely.
ZJ> Let's do this instead. We need more co-maintainership and more ZJ> co-operation in Fedora.
But it has all of the problems I outlined.
ZJ> Keeping an exisiting python2 subpackage is really no big deal.
Perhaps for you. Perhaps not for others. If it was no big deal in all cases then why have any python2 packages been dropped at all?
- J<
On Mon, Apr 09, 2018 at 12:55:04AM -0500, Jason L Tibbitts III wrote:
"ZJ" == Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
ZJ> Please don't. This is a repeat of the original idea of having ZJ> separate python3 packages back when python3 was being ZJ> introduced.
It seems that you are suggesting that pointless bureaucracy be kept in place purely because it slows down a process which you don't personally like. If so, that's awfully passive-aggressive.
If someone does wish too create a separate python2 package via a package review, will you also attempt to obstruct that review?
This is a misunderstanding. I wasn't speaking against the proposal to have a fast-track review process. I was speaking against the proposal to make those separate packages at all.
(If people create a separate package for python2 after all, I'm fine with an expedited review.)
ZJ> This was always a huge pain and waste of maintainer time.
I'm somewhat confused; you seem to wish to make it take more time, not less.
ZJ> Doing this on any massive scale would means hundreds (up to 2800?) ZJ> "new" packages, a way to burn massive amounts of maintainer time.
Has anyone at all suggested doing this on a massive scale? I certainly didn't. I only suggested making it easier to handle the case where a package maintainer simply doesn't want the python2 subpackage to be generated from the main package. I get the impression you took my suggestion and for whatever reason turned it into something else entirely.
ZJ> Let's do this instead. We need more co-maintainership and more ZJ> co-operation in Fedora.
But it has all of the problems I outlined.
ZJ> Keeping an exisiting python2 subpackage is really no big deal.
Perhaps for you. Perhaps not for others. If it was no big deal in all cases then why have any python2 packages been dropped at all?
That's a good question. So far I have seen the following: 1. dropping python2 support in leaf packages gradually and fix any issues one-by-one is easier then doing it in one step and then trying to rebuild everything. 2. dropping python2 support gradually makes people notice and raises awareness that they need to wean off python2. This applies to maintainers and non-maintainers alike. 3. removing support for python2 reduces maintenance burden. 4. apparently people don't like python2 and don't want to deal with it.
I share the sentiment behind all four points and I think they are all valid. The problem of when to remove support is to a large extent a matter of pushing work around. Removing support for python2 from a package makes life a bit easier for the maintainers of that package, and a bit harder for maintainers of dependent packages, and users. In my experience, the work to keep support for python2 at an existing level is not high, so when looking at the level of the whole distro, the positive gain from dropping support is smaller than the negative gain for people who have to update for that lost support. Thus, my feeling is that right now, it's better to keep it. If something major happens, like package upstream stopping support for python2, or dependencies going away, then there's a good reason to stop supporting python2.
Zbyszek
On 23.3.2018 12:23, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now.
Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 – many more than we can support without upstream help. We (rightly) don't have the authority to say "please drop your unneeded python2 subpackages, or let us drop them for you" [0]. The next best thing we *can* say is: "if Fedora is to keep python2 alive, we won't be the ones doing it – at least not at the current magnitude". Here are the details.
The current maintainers of python2 would like to "orphan" the python2 package in 2020 (~ Fedora 30):
- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)
As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
- dependent packages drop support for Python 2.
Unlike most other orphanings, we have some thousands of dependent packages, so a lot of time and care is required. In case no one steps up, we'd like to start dropping Python 2 support from dependent packages *now*, starting with ported libraries on whose python2 version nothing in Fedora depends. (We keep a list of those at [1].) Of course, we're ready to make various compromises with interested packagers, as long as there's an understanding that we won't just support python2 forever.
If you are a maintainer of anything at [1] we ask you kindly to consider removing the python2 subpackages. You can either do it now in Rawhide, or add a conditional for Fedora > 29. (On the current schedule, Fedora 30 will be the first release still supported after 2020-01-01.)
If no one steps up to maintain python2 after 2020, we're prepared to package a "legacy" python27 package, similar to what we do for e.g. python33 [2], to:
- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if
their upstreams don't manage to port to Python 3 in time
[0] https://pagure.io/packaging-committee/issue/753 [1] http://fedora.portingdb.xyz/#legacy-leaf [2] https://src.fedoraproject.org/rpms/python33/
This is just a reminder that nobody stepped up to maintain Python 2 after 2020. We still need to start dropping python2 packages.
What shall we do from here? File a Fedora System Wide Change Proposal for Fedora 30 that nothing explicitly white-listed to require Python 2 will be removed from Fedora? Can we even do that?
For context - there are currently 708 leaf packages [1](above).
Except several tools and applications, those are all modules that nothing in Fedora depends on. If we remove some, others only required by them will become leaf-packages as well.
We also have 1220 py2 only packages out of which plenty are probably unneeded modules as well, although we don't have the numbers.
As stated in the above e-mail in March, we are willing to support python2 for several (small number) of tools or apps. But we will not support it for 3 thousands of unused, unknown modules.
Python 2 will EOL in less than 1.5 year.
On Mon, 16 Jul 2018, Miro Hrončok wrote:
On 23.3.2018 12:23, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now.
tl;dr: --- that statement by itself overlooks the obvious. Not ALL packages become unsupported that first day of that year
Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance.
Not to be too direct about this, but isn't the RHEL 6 primary maintenance date (through 2020 11 30) a closer maintenance depot to look at and to compare against ?
Packages NOT in RHEL have a closer date, perhaps, but RHEL (next, assumedly 8, but ...) has not dropped yet. A subscription customer _should_ be migrating toward 7 at this point, but as this is not a costless thing, such migrations tend to be ... with a deliberate pace
-- Russ herrold
----- Original Message -----
From: "R P Herrold" herrold@owlriver.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Monday, July 16, 2018 8:57:11 PM Subject: Re: Intent to orphan Python 2
On Mon, 16 Jul 2018, Miro Hrončok wrote:
On 23.3.2018 12:23, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now.
tl;dr: --- that statement by itself overlooks the obvious. Not ALL packages become unsupported that first day of that year
Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance.
Not to be too direct about this, but isn't the RHEL 6 primary maintenance date (through 2020 11 30) a closer maintenance depot to look at and to compare against ?
I don't see how that relates to Fedora. Could you elaborate on what you mean?
Packages NOT in RHEL have a closer date, perhaps, but RHEL (next, assumedly 8, but ...) has not dropped yet. A subscription customer _should_ be migrating toward 7 at this point, but as this is not a costless thing, such migrations tend to be ... with a deliberate pace
Agreed but yet again, this doesn't like something that would impact Fedora.
-- Russ herrold _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis cstratak@redhat.com wrote:
----- Original Message -----
From: "R P Herrold" herrold@owlriver.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Monday, July 16, 2018 8:57:11 PM Subject: Re: Intent to orphan Python 2
On Mon, 16 Jul 2018, Miro Hrončok wrote:
On 23.3.2018 12:23, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now.
tl;dr: --- that statement by itself overlooks the obvious. Not ALL packages become unsupported that first day of that year
Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance.
Not to be too direct about this, but isn't the RHEL 6 primary maintenance date (through 2020 11 30) a closer maintenance depot to look at and to compare against ?
I don't see how that relates to Fedora. Could you elaborate on what you mean?
EPEL. Many of us use EPEL, with components from Fedora backported to our working environments. It's been an invaluable resource. Me? I just got a good look at openstack,, as well, which solved a *lot* of problems for me trying to bring some modules for communicating with proprietary data appliances into a RHEL environment. It's part of why so many Python modules have bothered to maintain Python 2 and Python 3 versions.
Packages NOT in RHEL have a closer date, perhaps, but RHEL (next, assumedly 8, but ...) has not dropped yet. A subscription customer _should_ be migrating toward 7 at this point, but as this is not a costless thing, such migrations tend to be ... with a deliberate pace
Agreed but yet again, this doesn't like something that would impact Fedora.
A lot of us use Fedora as a testing ground for our commercial work for the more RHEL and CentOS, and a source of bleeding edge tools. Good open source work is usually open to supporting multiple environments, so it's worth a thought.
On 17.7.2018 14:16, Nico Kadel-Garcia wrote:
On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis cstratak@redhat.com wrote:
----- Original Message -----
From: "R P Herrold" herrold@owlriver.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Monday, July 16, 2018 8:57:11 PM Subject: Re: Intent to orphan Python 2
On Mon, 16 Jul 2018, Miro Hrončok wrote:
On 23.3.2018 12:23, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now.
tl;dr: --- that statement by itself overlooks the obvious. Not ALL packages become unsupported that first day of that year
Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance.
Not to be too direct about this, but isn't the RHEL 6 primary maintenance date (through 2020 11 30) a closer maintenance depot to look at and to compare against ?
I don't see how that relates to Fedora. Could you elaborate on what you mean?
EPEL. Many of us use EPEL, with components from Fedora backported to our working environments. It's been an invaluable resource. Me? I just got a good look at openstack,, as well, which solved a *lot* of problems for me trying to bring some modules for communicating with proprietary data appliances into a RHEL environment. It's part of why so many Python modules have bothered to maintain Python 2 and Python 3 versions.
I hear you. I just don't understand what our action shall be according to you. Having python2 in Fedora might indeed be beneficial to old EPELs (and RHELs). But it shall not be an excuse to have thousands of modules packaged and supported because some of them might (or might not be) also present in EPEL. You can even use python3 in EPEL and call it a day.
Packages NOT in RHEL have a closer date, perhaps, but RHEL (next, assumedly 8, but ...) has not dropped yet. A subscription customer _should_ be migrating toward 7 at this point, but as this is not a costless thing, such migrations tend to be ... with a deliberate pace
Agreed but yet again, this doesn't like something that would impact Fedora.
A lot of us use Fedora as a testing ground for our commercial work for the more RHEL and CentOS, and a source of bleeding edge tools. Good open source work is usually open to supporting multiple environments, so it's worth a thought.
I (and now I'm speaking strictly for myself, other Fedora Python maintainers might have different opinion) won't spend my free time to maintain something I don't like just to support your commercial work. Will you? I don't have enough resources in my paid time to support Python 2 in Fedora **on the current scale**. That's what this topic was all about. Reduce the cruft, so we can keep it and support it in our paid time to support both commercial and non-commercial work. If not reduced, we cannot do that.
On Tue, Jul 17, 2018 at 1:43 PM, Miro Hrončok mhroncok@redhat.com wrote:
On 17.7.2018 14:16, Nico Kadel-Garcia wrote:
On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis cstratak@redhat.com wrote:
----- Original Message -----
From: "R P Herrold" herrold@owlriver.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Monday, July 16, 2018 8:57:11 PM Subject: Re: Intent to orphan Python 2
On Mon, 16 Jul 2018, Miro Hrončok wrote:
On 23.3.2018 12:23, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need to start dropping python2 packages now.
tl;dr: --- that statement by itself overlooks the obvious. Not ALL packages become unsupported that first day of that year
Python 2.7 will reach end of upstream support on 1st of January, 2020, after almost 10 years (!) of volunteer maintenance.
Not to be too direct about this, but isn't the RHEL 6 primary maintenance date (through 2020 11 30) a closer maintenance depot to look at and to compare against ?
I don't see how that relates to Fedora. Could you elaborate on what you mean?
EPEL. Many of us use EPEL, with components from Fedora backported to our working environments. It's been an invaluable resource. Me? I just got a good look at openstack,, as well, which solved a *lot* of problems for me trying to bring some modules for communicating with proprietary data appliances into a RHEL environment. It's part of why so many Python modules have bothered to maintain Python 2 and Python 3 versions.
I hear you. I just don't understand what our action shall be according to you. Having python2 in Fedora might indeed be beneficial to old EPELs (and RHELs). But it shall not be an excuse to have thousands of modules packaged and supported because some of them might (or might not be) also present in EPEL. You can even use python3 in EPEL and call it a day.
I was explaining why reasonable people involved in Fedora would care. I'm not saying never do it. It also happened with the perl 4 to perl 5 upgrade, for those of us who remember that, and when apache 1.x became httpd 2.x, and when Ruby updated to 2.x. Parallel support is possible and sometimes necessary.
What's happening now with Python has been pretty good, and I applaud the maintainers who've been forwarding Python 2 modules and the occasionally messy but overall effective logic of building parallel python2 and python3 modules. Python 2 *does* need to be replaced as the default. And I think at some point the logic will need to be reversed, that "with_python2" becomes the flag needed for building those older package, instead of the current "with_python3". That is going to be a pain in the *fundament* to port.
I (and now I'm speaking strictly for myself, other Fedora Python maintainers might have different opinion) won't spend my free time to maintain something I don't like just to support your commercial work. Will you? I don't have enough resources in my paid time to support Python 2 in Fedora **on the current scale**. That's what this topic was all about. Reduce the cruft, so we can keep it and support it in our paid time to support both commercial and non-commercial work. If not reduced, we cannot do that.
Your logic is sound. I publish patches to Fedora authors out of enlightened self interest for my paid work with RHEL and CentOS, and occasionally for the challenge of getting stuff into the bleeding edge systems. When RHEL 8 comes out, I hope it will be Python 3 based and I'll have the tools to mostly ignore Python 2, fostered by the good work happening in Fedora.
On 07/16/2018 11:15 AM, Miro Hrončok wrote:
This is just a reminder that nobody stepped up to maintain Python 2 after 2020. We still need to start dropping python2 packages.
What shall we do from here? File a Fedora System Wide Change Proposal for Fedora 30 that nothing explicitly white-listed to require Python 2 will be removed from Fedora? Can we even do that?
How would you construct the whitelist?
For context - there are currently 708 leaf packages [1](above).
Except several tools and applications, those are all modules that nothing in Fedora depends on. If we remove some, others only required by them will become leaf-packages as well.
We also have 1220 py2 only packages out of which plenty are probably unneeded modules as well, although we don't have the numbers.
As stated in the above e-mail in March, we are willing to support python2 for several (small number) of tools or apps. But we will not support it for 3 thousands of unused, unknown modules.
Python 2 will EOL in less than 1.5 year.
Could we perhaps look at moving python2 and everything that wants to use it into a module? I think that might make it more clear that it's not part of base Fedora and when it goes eol in f32 we drop it? That would take a lot of effort and duplication tho.
I don't think we want to drag this out too long... a clear call to drop all python2 in 31 (or I suppose f30) would be helpful and avoid some people dropping something other packages need, etc.
kevin
On 18.7.2018 00:03, Kevin Fenzi wrote:
On 07/16/2018 11:15 AM, Miro Hrončok wrote:
This is just a reminder that nobody stepped up to maintain Python 2 after 2020. We still need to start dropping python2 packages.
What shall we do from here? File a Fedora System Wide Change Proposal for Fedora 30 that nothing explicitly white-listed to require Python 2 will be removed from Fedora? Can we even do that?
How would you construct the whitelist?
Maintainers of apps and tools would whitelist their packages and we would recursively track dependencies. But that was a bit sarcastic from me, because I don't believe this would ever work (hence the "Can we even do that?" part).
For context - there are currently 708 leaf packages [1](above).
Except several tools and applications, those are all modules that nothing in Fedora depends on. If we remove some, others only required by them will become leaf-packages as well.
We also have 1220 py2 only packages out of which plenty are probably unneeded modules as well, although we don't have the numbers.
As stated in the above e-mail in March, we are willing to support python2 for several (small number) of tools or apps. But we will not support it for 3 thousands of unused, unknown modules.
Python 2 will EOL in less than 1.5 year.
Could we perhaps look at moving python2 and everything that wants to use it into a module? I think that might make it more clear that it's not part of base Fedora and when it goes eol in f32 we drop it? That would take a lot of effort and duplication tho.
That would be very painful and would request an extraordinary amount of manpower while gaining zero benefit (except that we would have the ability to drop it mid-realease). The drop can wait until that Fedora EOLs.
I don't think we want to drag this out too long... a clear call to drop all python2 in 31 (or I suppose f30) would be helpful and avoid some people dropping something other packages need, etc.
We can call for that but we know that it is not possible. There are Python 2 powered apps in Fedora that could seriously disturb the distro if dropped.
To name a few:
fedora-easy-karma fedora-packager fedora-review chromium nodejs datagrepper datanommer fedwatch gimp inkscape mercurial xen ...
We want to keep them and we are able to maintain Python 2 for them (well, we would very much prefer to have them ported to Python 3 but we realize it's not always happening.)
On 07/17/2018 04:35 PM, Miro Hrončok wrote: ...snip...
We want to keep them and we are able to maintain Python 2 for them (well, we would very much prefer to have them ported to Python 3 but we realize it's not always happening.)
Well, if something is broken in python2, breaking one of the packages you want to maintain it for, likely it's broken for other packages too? But I see what you mean...
One of the reasons I suggested modules was that it would take concrete work for packages that still need python2 to become modular and depend on a python2 module, making it easier to just retire everything in the main collection that doesn't take any action.
I think without that you are back to a whitelist... "all python2 dependent packages will be retired in F30, except the ones on this list" and you will have to detect those.
kevin
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Bill Nottingham -
Charalampos Stratakis -
Eric Garver -
Fabio Valentini -
Gerald Henriksen -
James Hogarth -
Jason L Tibbitts III -
Jerry James -
Kevin Fenzi -
Kevin Kofler -
Matthew Miller -
Matěj Cepl -
Miro Hrončok -
Nico Kadel-Garcia -
Peter Oliver -
Petr Viktorin -
R P Herrold -
Ralf Corsepius -
Randy Barlow -
Rex Dieter -
Richard W.M. Jones -
Silvia Sánchez -
stan -
Zbigniew Jędrzejewski-Szmek