Dear Python packagers, Am 26.12.20 um 16:01 schrieb Ben Greiner:
Am 25.12.20 um 18:34 schrieb Dominique Leuenberger / DimStar an factory@lists.opensuse.org:
* Multiple python 3 versions parallel installable. Adding to python 3.8, version 3.6 will be reintroduced. Python modules will be built for both versions.
Last Friday evening, all checks for Staging:N were successful and the associated submissions were accepted into openSUSE:Factory. As of now, no snapshot with the changes has been released, and many packages show as unresolvable because the appropriate python36-foo and python38-foo have not been published yet. Hopefully this will be fixed after the maintainers come out of their well deserved weekend. This leaves us with a pressing task:
- If upstream does not support python 3.6 anymore (Numpy already deprecates to support it in new releases, according to NEP 29 [5]) you can use `%define skip_python36 1`. All depending packages need to do the same. Alternatively a branched package can provide an older version for this flavor, e.g. python-ipython715 has been created to provide the last version which support Python 3.6.
SciPy's recent update to 1.6.0 already dropped support for Python 3.6. Luckily for us, the update is stuck in Staging:I, and :N got merged before it. But in order to move on in the spirit of Tumbleweed, we need to `%define skip_python36 1` in python-scipy. As a consequence, all packages requiring python-scipy need to do the same, unless someone steps up to create and maintain a legacy python-scipy15 package (and one for numpy119, see below). Expect a lot of submit request in the next few days, and please help with proactively making the changes in packages, which you care about. For an even larger set of packages, the same will be required for NumPy in the near future. NumPy 1.20 already has has an rc2 and will also drop Python 3.6 following its own NEP 29. Note that from Tumbleweed's point of view, this does not mean to *drop* Python 3.6 support, as Python 3.6 packages have not been on Tumbleweed since the arrival of Python 3.7. It rather prevents (or reverses the very short period of) the reintroduction of those legacy version packages. If your package's dependency on scipy is only optional and upstream still officially supports python 3.6, please consider providing the python36 flavor as long as upstream does it, and just remove the requirement for python <=3.6 while deselecting scipy specific tests. This way, you don't break the package in d:l:p:backports (if it is not already broken). Regards, Ben