Non-integrated packages in devel:languages:python:
devel:languages:python/python-aiocontextvars
devel:languages:python/python-buildozer
devel:languages:python/python-dnspython1
devel:languages:python/python-frozenlist
devel:languages:python/python-lastversion
devel:languages:python/python-mysql-to-sqlite3
devel:languages:python/python-nr.collections
devel:languages:python/python-nr.fs
devel:languages:python/python-nr.metaclass
devel:languages:python/python-nr.pylang.utils
devel:languages:python/python-nr.types
devel:languages:python/python-nr.utils.re
devel:languages:python/python-plyer
devel:languages:python/python-rdopkg
devel:languages:python/python-sqlite3-to-mysql
devel:languages:python/python-stripe
Packages with diff in devel:languages:python:
devel:languages:python/python-M2Crypto
devel:languages:python/python-jedi
devel:languages:python/python-mocket
devel:languages:python/python-parso
devel:languages:python/python-sphinx-autodoc-typehints
devel:languages:python/python-vdirsyncer
Non-integrated packages in devel:languages:python:avocado:
devel:languages:python:avocado/python-Fabric
devel:languages:python:avocado/python-fluidity-sm
devel:languages:python:avocado/python-invoke
devel:languages:python:avocado/python-lexicon
devel:languages:python:avocado/python-unittest2
Packages with diff in devel:languages:python:avocado:
Non-integrated packages in devel:languages:python:aws:
Packages with diff in devel:languages:python:aws:
Non-integrated packages in devel:languages:python:azure:
devel:languages:python:azure/python-azure-core-tracing-opentelemetry
devel:languages:python:azure/python-azure-mgmt-portal
devel:languages:python:azure/python-azure-mgmt-powerbidedicated
Packages with diff in devel:languages:python:azure:
devel:languages:python:azure/python-azure-mgmt-hdinsight
Non-integrated packages in devel:languages:python:certbot:
Packages with diff in devel:languages:python:certbot:
Non-integrated packages in devel:languages:python:django:
devel:languages:python:django/python-django-tables2
Packages with diff in devel:languages:python:django:
Non-integrated packages in devel:languages:python:Factory:
devel:languages:python:Factory/pypy3
Packages with diff in devel:languages:python:Factory:
Non-integrated packages in devel:languages:python:flask:
Packages with diff in devel:languages:python:flask:
Non-integrated packages in devel:languages:python:jupyter:
Packages with diff in devel:languages:python:jupyter:
Non-integrated packages in devel:languages:python:numeric:
Packages with diff in devel:languages:python:numeric:
devel:languages:python:numeric/python-Pint
devel:languages:python:numeric/python-pyerfa
Non-integrated packages in devel:languages:python:pyramid:
Packages with diff in devel:languages:python:pyramid:
Non-integrated packages in devel:languages:python:pytest:
Packages with diff in devel:languages:python:pytest:
devel:languages:python:pytest/python-py
Hello,
my apologies in advance if this mail reaches you up to three times, but
in my opinion the topic is relevant and important to reach people
subscribed to all three mailing lists.
Am 25.12.20 um 18:34 schrieb Dominique Leuenberger / DimStar an
factory(a)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.
This line sounds rather innocent, but it has severe implications:
Every package python-foo, which uses the so called singlespec macro
%python_subpackages, will also try to build a python36-foo package. The
whole build process will fail if a step in that particular flavor fails
or if building for more than one flavor will create conflicts. We took
care [1] of all the packages in Ring0 and Ring1, which popped up as
problematic in the staging project. But there are many more packages,
which will see the change the first time, when the staging project will
be accepted into Factory. You can refer to the documented changes in [1]
for examples how to fix a package. There are also some updates to the
wiki [2] and the documentation of python-rpm-macros [3].
In particular, look out for:
- Packages already skipping Python 2 will start to produce more than one
package. Avoid duplicate files by using update-alternatives (there are
macros for it in python-rpm-macros), or put common files into unflavored
subpackages.
- If you provide or require python3-foo, it will only do that for the
primary python interpreter. Replace `BuildRequires python3-foo` by
`BuildRequires %{python_module foo}` and let the %python_subpackages
macro do the work for all Tags and macros where it can replace the
unflavored variants e.g.:
* `Requires: python-bar` instead of python3-bar.
* `%python_sitelib` instead of `%python3_sitelib` in `%files`
- Some packages need extra packages backporting stuff to Python 3.6,
e.g. importlib-metadata or dataclasses. See black as an example how to
deal with this [4]
- 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.
- Python "apps" not following the flavored python-foo naming scheme,
will only collect files for one (hopefully the primary python3
providing) flavor during the packaging phase. Remove %python_modules,
%python_build, %python_install, %python_expand and the sort, as it
unnecessarily pulls in packages for all python flavors and tries to
build and install into multiple sitelib/sitearch directories. Replace by
calling python3 directly or use the equivalent %python3_* macros.
- Some non-singlespec packages only create python3-foo. They will either
need an update to include python36-foo, python38-foo (and python39-foo
in the near future), or all depending packages must only build for the
primary python3, too. `%define pythons python3` or skip all non-primary
interpreters.
- The previous item is also true for many packages, which have a python
bindings subpackage but are not Python only. We introduced
%python_subpackage_only so that these packages now can take advantage of
the singlespec macros as well. The tracker comment on GitHub [6] has
links to a few examples how to use it.
- %ifpython3 and %python3_only are evil. They have been deprecated for
some months already. Essentially, they fail to recognize the new flavors
python36 and python38 which replace python3. OTOH, older distributions
will continue to use the python3 flavor. We have introduced a new
%python_provides macro, but did not modify %ifpython3 or %python3_only
to incorporate this, because it is not automatically clear whether the
conditioned code block shall apply to all flavors of Python3 packages or
only to the primary interpreter. Replace by something like
* `%if "%{python_flavor}" == "python3" || "%{?python_provides}" ==
"python3"` for sections only provided by the primary flavor.
* `%if 0%{python_version_nodots} > 34` or `%if "%{python_flavor}" !=
"python2"` for section applicable to all Python 3 flavors.
Cheers and happy coding,
Ben
[1] https://github.com/openSUSE/python-rpm-macros/issues/66
[2] https://en.opensuse.org/openSUSE:Packaging_Python
[3] https://github.com/openSUSE/python-rpm-macros/blob/master/README.md
[4] https://build.opensuse.org/request/show/853412
[5] https://numpy.org/neps/nep-0029-deprecation_policy.html
[6]
https://github.com/openSUSE/python-rpm-macros/issues/66#issuecomment-715538…