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.)
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.
We need to communicate loudly that Python 2 is dead. And this is a way
to do it. If the maintainrs add conditionals for Fedora 33, let them
have it. But every single python2 package that goes away is a good thing
longterm both for Fedora and for the Python ecosystem.
> If we want to prepare for the python2-eol, IMHO we should first finish
> all the steps that don't impact users: convert our tooling, make sure
> python2 is not used in build for anything where python3 can be used,
> rename packages, fix provides and requires, update she-bangs, add
> conditionals to make dropping python2 support easy. In particular,
> let's first finish Changes/Avoid_usr_bin_python_in_RPM_Build.
Yes, we should focus on that. But if we don't do things in parallel, we
have very little chance to move forward fast enough.
[1]
https://developer.fedoraproject.org/tech/languages/python/python-installation.html
[2] https://fedoraproject.org/wiki/Changes/Django20
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
