On 03/20/18 14:45, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 20, 2018 at 12:23:06PM +0100, Miro Hrončok wrote:
On 20.3.2018 11:25, Zbigniew Jędrzejewski-Szmek wrote:
to push the whole ecosystem. The proposed model of nipping python2 support
at the edges is the same thing, in reverse. First some leaf packages
are dropped, and then some somewhat more important packages, and then
suddenly it becomes hard to use python2 for anything "serious", even
though it's still "available". I think that's a bad way to proceed for
our users. Let them have a single moment where python2 support goes away.
Announce this moment at least a year in advance. Let them keep running
the last release before that for as long as they need.
I think there is a fundamental difference of how I see python RPMs
in Fedora and how you do. In my POV, purpose of pythonX-foo packages
that only bring libraries is to provide dependency for an
application that happens to be written in python, runs on pythonX
and need the foo library. If there is no such application packaged
in Fedora, I see no purpose of such package. (Except maybe if such
app is packaged in another repository used by our users. That's a
corner case and if the maintainer of pythonX-foo is aware of that,
it can always be used as argument to keep pythonX-foo.)
Indeed, I'm using those python packages like a dinosaur ;)
But more seriously, I think the distinction between library and app in
the python world is neither clear nor particularly significant. Distro
packaging provides clear benefits in both cases: easy and quick
install, easy and quick uninstall, testing, provenance history,
license checks, general reliability.
So instead of losing packages, I'd like to see more automatic
packaging and updates of packages from pypi and other "forges".
We are making steps in that direction, but not quickly enough.
We live in an era of pip (and rubygems, and cpan, and npm etc.).
Trying to mirror those systems with RPM packages just because it's
possible is tedious, incomplete and mostly pointless IMHO. An era
when upstream projects were eager to get their tool into the distros
has passed. Having pythonX-foo packaged where no other
tool/app/service needs it is not beneficial (if foo is a library
only thing, not a tool itself). I have this opinion even with
python3 packages.
Developers who wants to use python2 for whatever reasons (rational
or emotional ones) can do that on Fedora. We encourage developers to
use virtual environments and pip [1]. Removing leaf python2 packages
does not block them here at all.
Let them have a single moment where python2 support goes away.
Removing all python2 things at one point is impossible. We've tried
to test this with Django [2] on a much smaller scale. (Tens instead
of thousands packages.) It took us too much time and too much
energy. At the end, too much packages were just retired because
their maintainers are "dead". I cannot imagine doing this on current
scale in 2020.
We can just retire python2 then and see what breaks. Honestly,
everything would break.
I don't think this is entirely comparable. Django20 was about updating
packages and switching support from python2 to python3. Just dropping
existing support for python2 is something much easier.
Maybe it's much easier, but it's still not trivial.
I just saw a package that uses epydoc to generate its documentation,
from its py2 code. Since epydoc is not ported, that package would lose
its documentation if python2 was just suddenly dropped – and we wouldn't
know in advance, because the package was in the "dual py2/py3 support"
bucket.
But I'm not complaining about epydoc in general. I'm afraid there are
many more cases like that – cases where we won't know about the problem
until we try to remove the py2 packages. Especially those with
unresponsive maintainers, which tend to use the most interesting ancient
technology.
I don't see a good way to uncover such problems other than to start
removing stuff.
Nevertheless, I agree that this still is a very significant chunk of
work at this scale. So spreading this out makes a lot of sense, but
imho python2 subpackages don't need to go away, they can just be
conditionalized.
What about adding conditionals like
%if 0%{?rhel} > 7 || 0%{?fedora} > 31
# Disable python2 build by default
%bcond_with python2
%else
%bcond_without python2
%endif
starting now?
Agreed, we just need to bikeshed the "31" number there.
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
