Deploy packages for CentOS 8 and Fedora 31

[Totktonada]

Known problems on CentOS 8

No python-setuptools and python-msgpack packages. There is python3-setuptools in the standard repositories and python3-msgpack in EPEL.

NB: How to better define dependency on EPEL in RPM spec? Or it is better ship python3-msgpack from our repositories?

See also tarantool/tarantool#4611 (comment)

Known problems on Fedora 31

Unlike CentOS 8 there are python-setuptools and python-msgpack aliases for python3-setuptools and python3-msgpack (however I think it would be better to depend on the latter ones directly).

But there is no python command, only python3, so python setup.py <...> commands fails.

[DifferentialOrange]

CentOS 8 is not relevant anymore.

Regarding python setup.py <...>: it seems that we need to remove direct setup.py calls:

While it is perfectly fine that users write setup.py files to configure a package build (e.g. to specify binary extensions or customize commands), on recent versions of setuptools, running python setup.py directly as a script is considered deprecated. This also means that users should avoid running commands directly via python setup.py .

See https://setuptools.pypa.io/en/latest/deprecated/commands.html

It doesn't mean that there won't be any python ... calls, but it's a good place to start.

[Totktonada]

Also from this document:

Build [python -m build <...> is meant] will automatically download setuptools and build the package in an isolated environment.

In my understanding a network interaction during a package build/installation is a bad practice. At least it is banned by default in Gentoo: if a package tries to access a network at particular stages, it leads to sandbox rules violation error and fails the build.

So I would rather follow Fedora packaging guidelines for Python packages. I can't suggest anything definite, I have no experience here.

python setup.py <...> is likely not the best option for packaging too.

---

The recommendation regarding python -m build <...> may be valuable in context of the releasing guide for PyPI (but we should verify it in our case first).