python2-notebook is a leaf package (nothing in Fedora (build)requires
it). I'd like to drop it from rawhide. Any objections?
This **does not** affect the ability to run Jupyter Notebook (via the
jupyter-notebook command) with Python 2 kernel (from the
Dear python devel,
I just noticed that since Fedora 28, package python2-firewall is no longer
available and while I know that python2 packages nobody seems to rely on
are being gradually removed nowadays, I wonder why exactly was this
particular package removed.
The problem here is that without python2 module for firewalld, one can't
use an ansible playbook to reconfigure firewall on Fedora machine:
And while switching to python3 may solve this particular problem, I
don't think it's a reasonable solution from Fedora perspective, which:
* packages Ansible so that it runs on python 2
* provides Firewalld to manage firewall by default
Decision to drop python2-firewall then looks little weird, as it breaks
the general expectation that ansible playbook using firewalld module is
able to reconfigure firewall on a fedora machine. Moreover other python2
modules which some ansible modules are using such as python2-libselinux
or python2-dnf are still available, and dropping python2-firewall
doesn't look very consistent. That said, these python2 subpackages will
not be installed by default.
The other problem here is that it's not easy to spot such problem, as
this kind of dependency is not visible via rpm requirements (see eg. BZ
1505082 for explanation :). Maintainer dropping his python2 subpackage
could very easily miss this.
What do you think? Do we want to continue dropping python2 modules and
encourage people to reconfigure ansible to run under python 3 while
shipping ansible with python 2 or do we want to keep python2 modules
used by ansible available, even thouhg this is not easy to track right
And don't get me wrong, I'm a fan of switching to python3 and I agree
that helping ansible guys with python 3 testing and porting is good
for Fedora. I just don't think that dropping random packages from
distribution so that random modules doesn't work with default ansible
is a good way to do it.
At PyCon US 2018, Łukasz Langa, the release manager for Python 3.7, told
me that he'd like to collect data about Release Candidates for point
releases (3.x.y). The idea is that if these aren't being tested and
aren't revealing bugs, it would make sense to stop releasing them.
So, please, if you find any bugs in upcoming Python *3.6.x* release
candidates, let me know (or write to Łukasz directly)! If there are no
such reports, there will be no 3.7.x RCs.
Also, are these useful for Fedora? Do/should we test 3.x.y RCs?
(3.x.0 pre-releases like the current 3.7.0 beta are a different matter;
those are obviously useful.)
I'd like to retire python33 from Fedora 29+.
Upstream has ended 3.3 support in September 2017 . It was security
only since October 2014.
Red Hat does not support 3.3 in any of the products (AFAIK). Software
collection python33 is EOL since Oct 2016 .
Python 3.3 was somehow important with OpenShift Online 2, because that
was the only out of the box working Python 3. OpenShift Online 2 is EOL
since December 2017 .
Debian jessie (oldstable) has Python 3.4. Debian wheezy (oldoldstable)
has 3.2 so that one is irrelevant anyway (regardless being oldold).
Ubuntu 14.04 LTS has 3.4. Ubuntu 12.04 LTS has EOLed in August 2017 and
had 3.2 anyway.
I see no reason a developer would need to test their code against Python
3.3 in 2018. However I might be missing something. If nobody speaks up,
I'll retire python33 in 1-2 weeks.
Probably some, or most, of you have already seen this but I
find Randall Munroe's cartoon right on the point (for most
issues and this about python is not an exception):