Mingw-packages: Drop Python 2 packages

[lazka]

Here is a list of leaf packages containing "python2" for starters.

Any thoughts on dropping them?

edit: removed, outdated

[totaam]

Can we wait until after python2 is EOLed? (2020)

[lazka]

Sure, I just wanted to get the discussion started with a first target (Arch is doing the same right now).

Do you need any package of the list above?

[lazka]

An alternative to dropping packages might be to stop accepting Python 2 packages without a good reason i.e. only build new Python packages for Python 3.

[totaam]

Do you need any package of the list above?

Yes - OTOH:

• mingw-w64-gst-python2
• mingw-w64-python2-PyOpenGL
• mingw-w64-python2-comtypes
• mingw-w64-python2-cx_Freeze
• mingw-w64-python2-ldap
• mingw-w64-python2-ldap3
• mingw-w64-python2-lz4
• mingw-w64-python2-nvidia-ml
• mingw-w64-python2-paramiko
• mingw-w64-python2-pkginfo (indirectly)
• mingw-w64-python2-pyu2f
• mingw-w64-python2-setproctitle
• mingw-w64-python2-zeroconf

And when they get removed... we'll probably have to maintain them by hand for a little while.
(same as centos6 and python2.6... some things move slowly)

An alternative to dropping packages might be to stop accepting Python 2 packages without a good reason

I'm fine with that, got mine in just in time ;)

[lazka]

OK, thanks for the list.

Let's try to be a bit stricter on adding new packages for starters and re-evaluate next year.

[danyeaw]

In preparation for this, could we rename all the python3 packages to just python?

[spl1inter]

Disambiguation from upcoming python 4?

[lazka]

In preparation for this, could we rename all the python3 packages to just python?

I was more thinking that this might reduce the amount of work, and renaming everything goes a bit against that :)

[peterbud]

What is our strategy for packages whose new versions do not support anymore python2 (e.g. sphinx)? Arch has simply dropped python2, but not sure what we shall do with those?

[lazka]

In case of matplotlib I've split things up into a python2 and a python3 PKGBUILD: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python2-matplotlib https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python3-matplotlib (and adjusted pkgbase accordingly)

[peterbud]

Thanks @lazka this makes sense to me

[lazka]

@totaam any progress on your side? Just wondering.. :)

[totaam]

@totaam any progress on your side? Just wondering.. :)

Sort of. Xpra LTS 3.0 has been released.
I'm waiting for some fixes from 3.0.1 to submit a pull request for mingw.
It supports both python2 and python3, though python3 is now the default.
So I will be supporting both for about 3 years. :(
Which means that I would be glad to help when a package needs to be split into 2 because newer versions have dropped support for python2 then I'll do that. (just like matplotlib)
If and when python2 packages are removed from the tree, it would be nice to create a tag that I can quickly switch to in case I need to rebuild something.

[lazka]

Sort of. Xpra LTS 3.0 has been released.
I'm waiting for some fixes from 3.0.1 to submit a pull request for mingw.
It supports both python2 and python3, though python3 is now the default.
So I will be supporting both for about 3 years. :(

That's a start at least :)

Which means that I would be glad to help when a package needs to be split into 2 because newer versions have dropped support for python2 then I'll do that. (just like matplotlib)
If and when python2 packages are removed from the tree, it would be nice to create a tag that I can quickly switch to in case I need to rebuild something.

ok, thanks, I'll ping you if needed. It's probably better to create your own repo and collect py2 variants there.

[lazka]

@totaam just wondering.. I assume you ship self contained Windows packages, so why can't just use Python 3 there?

[lazka]

I've started something in #6009

[totaam]

@totaam just wondering.. I assume you ship self contained Windows packages, so why can't just use Python 3 there?

Yes, we ship self-contained installers on MS Windows and MacOS.
We have both Python2 and Python3 builds from the same codebase. I wished we could drop the Python2 version sooner rather than later, but this looks unlikely:

• we support centos, including centos7, which means supporting python2 until that is EOL
• GTK2, which is Python2 only, is still way more stable and reliable that GTK3 on some platforms, including MS Windows and MacOS.

[lazka]

Here is an auto-updating list of packages that depend on Python 2: https://packages.msys2.org/python2

[lazka]

About 140 packages are done now. I'll continue this next year.

[Ede123]

It seems in contrast to the initial announcement to "remove a few leaf packages" this has now become a mission to completely purge python2?

I've just noticed, as you've removed python2-pip, which effectively crippled the build system for Inkscape's stable branch (0.92.x) that was also supposed to become kind of a "long-term support" release for people to facilitate the move to the upcoming Inkscape 1.0.

The idea was to keep 0.92.x on Python 2 for backwards-compatibility; 1.0 will obviously be using Python 3. However I'm having doubts if I can still keep my promise to offer a working 0.92.x LTS branch if my build system is falling apart...

[lazka]

It wasn't my plan to drop pip at least..

[lazka]

Maybe we can add setuptools/pip back with vendored dependencies.

[Ede123]

That would be nice - especially as installing an old package is not easily possible either as python3-pip has now files that are conflicting with python2-pip, so basically there currently would be no feasible way to keep python2.

[lazka]

Yeah, alexey was a bit overzealous there, but I'm also quite happy he helped as removing all those package was quite a lot of work.

[danyeaw]

If we are going to keep Python2, is someone signing up to downstream patch Python2 if a security vulnerability is found? 2.7.18 is the final release.

[totaam]

is someone signing up to downstream patch Python2 if a security vulnerability is found?

Sure, why not.
There's clearly more than enough people who will be needing that, not even counting the distros that will do it themselves - ie: RHEL7 / CentOS7.

[lazka]

I've started something in #6070 to add back setuptools with vendored dependencies, which seems to work OK based on some limited testing.

[lazka]

pip2 is back now. Please give it a try.

[Ede123]

First tests look promising, thanks @lazka !

[lazka]

Short status update, we are down to 21 packages: https://packages.msys2.org/python2

There are a few things which probably can still be removed, like build rust/qt/graphviz with Python3. Then there is wxpython 4 (and in turn kicad) which in theory supports Python 3 but it has it's own build system which hardcodes msvc, so unlikely for now. And then there are the cases where things are not libraries and don't support Python 3 yet.

I'd say that this is more or less done, so closing :)

[lazka]

I've opened a PR to remove the cygwin version of Python 2, including pip and setuptools. Is anyone using that still? -> https://github.com/msys2/MSYS2-packages/pull/2131

[Ede123]

For Inkscape we depend on it indirectly via "gnome-doc-utils" (which already broke before due to libxml2 / libxml2-python not being compatible anymore).

It's all scheduled for replacement but without a due date yet. Will it still be possible to install those packages manually for the time being?

[Biswa96]

By 'manually', if you mean downloading .tar.xz from Pacman repository then I think yes.

[Ede123]

Yes, that's what I mean. The problem with the mingw64 update was that there were conflicting files, so you could not install the old Python 2 and Python 3 side-by-side.

[lazka]

If gnome-doc-utils doesn't work, please file a bug here.