Python 3 versions

[Alexander Bokovoy]

On ke, 28 maalis 2018, Andrew Bartlett via samba-technical wrote:
> On Wed, 2018-03-28 at 15:42 +1300, Douglas Bagnall via samba-technical
> wrote:
> > On a Github pull request regarding Python 3 porting
> > (https://github.com/samba-team/samba/pull/152), Joe Guo pointed out
> > that the following construct
> > 
> > >          :return: list with key names
> > >          """
> > > -        data = self.db.get("%s\x00" % key)
> > > +        data = self.db.get(b"%s\x00" % key)
> > >          if data is None:
> > >              return []
> > 
> > uses printf style formatting on a bytes object, which is supported in
> > Python 3.5 (and 2.[67]) but not Python 3.4. Our autobuild box runs
> > Ubuntu 14.04 with Python 3.4, so we currently can't do this.
> > 
> > This is not difficult to work around, but it is one more thing that
> > makes me yearn to skip 3.4 and just go to 3.5 or 3.6, before anyone
> > actually relies on Python 3. For example, the async/await syntax looks
> > useful, at least for testing:
> > 
> > https://docs.python.org/3/whatsnew/3.5.html#pep-492-coroutines-with-async-and-await-syntax
> > 
> > But if we allow a 3.4-reliant release to get on an 3.4-reliant
> > enterprise distro, we won't be able to use this for, you know,
> > decades.
> > 
> > So I am asking: is a 3.5 minimum remotely possible? Are there going to
> > be long-lived enterprise releases that have Python 3.4? Can we upgrade
> > sn-devel and forget 3.4 existed?
> > 
> > I guess there is another tricky question around supporting e.g.
> > RHEL/Centos 7, where Python 2.7 is king but a 3.x is available. How
> > quickly can we drop 2.7 support and push Samba on those machines to
> > 3.x?
> 
> I totally agree, when we lock onto a python3 baseline we need it should
> be as recent as practical.  I also think we should drop Python2 as soon
> as we have python3 fully working, as otherwise there will be an
> insistence long-term on the py2 stuff.  (This transition has already
> cost us an incredible amount of resource, staying dual-stack long-term
> is just silly). 
Latest time to drop py2 support is 2020 -- this is when Python upstream
ends Python 2 support completely and finally. Distributions are working
on deprecating py2 environments too by that time.

Of course, one could argue that we have to build on older systems (say,
CentOS 7) which have no Python 3 in the system provides, but I'd rather
look forward than be tied to old bases. As can be seen with Ubuntu
below, there are python3.6 versions available there, and IUS community
provides the same for CentOS/RHEL:
https://ius.io/
https://janikarhunen.fi/how-to-install-python-3-6-1-on-centos-7.html
 
> For the immediate future, keeping with 3.4 is the most practical
> option, but we need to move past that quickly.
> 
> In practical terms, we can install python 3.6 in the docker image used
> for CI on gitlab and we can move travis-ci to using docker as well. 
> Fixing the packer script for the image used at Catalyst is also fairly
> practical.  That just leaves sn-devel, hopefully the root folks can let
> us know if that is possible.
> 
> The alternative is that we get sn-devel (and the docker/cloud images)
> up to 18.04, which helps us on a number of fronts.  Depending on the
> root folks, that might be possible before 4.9 freezes for example.
There are python3.6 packages available for 14.04 and other Ubuntu
versions:
https://askubuntu.com/questions/865554/how-do-i-install-python-3-6-using-apt-get

-- 
/ Alexander Bokovoy