Drop Python2 for the build?

[Nico Kadel-Garcia]

On Fri, Sep 4, 2020 at 10:23 PM Andrew Bartlett via samba-technical
<samba-technical at lists.samba.org> wrote:
>
> Just wondering when might be the time to drop the python2 build?
>
> This came to mind because David Disseldorp recently had to adjust build
> system changes to cope with python2, so I figured it might be time to
> revisit this.
>
> March 2021 will be 12 months after the long-delayed EOL for Python2 and
> since we made last made big decisions around this area Python3 has
> become available in the default package set for more platforms,
> particularly including CentOS 7.

I yanked python2 support out of my published RPM building tools quite
some time ago. There are some weirdnesses in RHEL 7 and CentOS 7,
because some packages from EPEL are named "python36-[module]" but
don't provide "python3-[module]" unlike the current base OS packages
for CentOS and RHEL, and they're due for an update in EPEL to resolve
the discrepancy. Red Hat's selection to publish the python3 packages
as "python3-" instead of following EPEL's "python36-[module]" naming
convention has been a source of confusion, and it's even worse with
Amazon Linux 2 where the "python3-[module]" packages are python 3.7,
not python 3.6, and the incompatibility with EPEL is a real problem. I
can't currently build my Samba packaging on Amazon Linux 2 without
building up a dependency chain of those spare python3 modules.

The dependency chains and sometimes inconsistent availability of
python modules and dependency chains for them among python2, python3,
and different operating system releases is a serious pain in my
keister and eats cycles I could burn better elsewhere.. "pip install"
is not my friend when contemporary versions of modules are not
compatible with each other, and when two modules have dependencies on
incompatible versions of the same module. Simplifying this by
discarding an obsolete build environment makes eminent sense.

> We currently spend CI resources building and smoke testing Samba with a
> python2, which we could save, as well as the (small) complexity of
> targeting both python versions.

Please, yes.

> The simplest change would change the minimum python to build Samba to
> 3.5, the same as we set the minimum to for fuzzing, or just 3.6 the
> same as we already require otherwise (this would be better tested).

3.6 is the python 3 base for both CentOS 7 and CentOS 8, so I'd be
happy with that.

> As background, the first Samba release with python3 support, 4.10, was
> released in March 2019, so if we did this for 4.14 this would be a two-
> year gap.
>
> What do folks think?
>
> Importantly: beyond Linux, how is python3 platform support better now?
>
> Thanks,

MacOS has working python3 according to my developer friends. Any
operating still based on python3 is so old that it should *not* be
running a contemporary Samba server, only perhaps cifs-utils for
mounting from Windows or Samba servers on a more contemporary and
securable operating system.