Setup Python 3 and modules in RPM-based containers

[ligurio]

Set current Python interpreter version used in containers [1].

1. https://gitlab.com/tarantool/tarantool/-/pipelines/243731352

Part of tarantool/tarantool#5652

[Totktonada]

I doubt about settings Python 3 by default for recent Fedora distros in the general purpose build images, because it contradicts with the distribution policy. It contradicts even more with CentOS 7 defaults, because here Python 2 is assumed when just python is called.

AFAIK, the problem is that when we'll add support Python 3 in addition to Python 2 into our testing framework, we'll set shebang to #!/usr/bin/env python. It is perfectly logical step, but it leads to problems on modern Fedora distros, where python is not aliased with anything (neither python2, nor python3).

I see several other ways to overcome the problem (fully or partially):

1. Most simple: just change the shebang to #!/usr/bin/env python3. All distributions, where we run testing, (CentOS 7/8, Fedora 28-32, openSUSE Leap 15.1/15.2, Debian 9/10) now have ways to install the python3 even if default is python2 (or if there is no default). At least I hope it is so. However there is the problem with python3-six / python3-gevent packages availability¹².
2. Keep the shebang #!/usr/bin/env python and create a Bourne shell runner, which find available Python interpreters and run the script using, say, most modern one (but prefer just python when available). This way should work seamlessly everywhere³.
3. The same as 2, but don't create a wrapper and rather implement the interpreter choosing logic under the make test and make test-force goals in tarantool (and vshard?).
4. The same as 2, but use the dark magic to place the shell wrapper right inside the main python script (or vice versa). Looks ugly, to be honest, but should work.

I vote for the second, but any of {2, 3, 4} looks acceptable for me.

Footnotes:

---

Set arbitrary Python interpreter version

AFAIS, you set certain versions of the interpreter, not arbitrary. And it is always Python 3.x.

Footnotes

1. There are at least two workaround. First, we can preinstall necessary packages within packpack images using pip and eliminate explicit dependencies in the spec file. I would consider this way as the last resort. Second, we can build needed modules using the distribution's source packages and place resulting RPMs into the backports packpack repository. It'll require constant effort to rebuild those packages for new distros, so I would want to avoid this. Of course, we can eliminate six dependency (all its usages are quite simple to be backported) and can port gevent code to the modern async / await, but it'll require more effort and does not look worthful at the moment. ↩

2. I would add that I don't like the decision made by Fedora maintainers. I understand, it is the compromise for the transition period from Python 2 to Python 3, and compromises are unavoidable for given amount of work to perform the transition. However I would consider shebang rewriting rule as distro local policy, which should not be applied across this scope. Only when you package a Python script for Fedora. ↩

3. It is more or less like Gentoo works with Python scripts. ↩

[ligurio]

Updated PR, decided to use python3 in shebangs. So in the rest we need py3 modules in test environment (six, gevent, msgpack and pyyaml).

[Totktonada]

So, what is the fate of this pull request?

[ligurio]

We don't need these changes.