RFC: CI limitations and using 'six' module for python2/3 compatability

[Alexander Bokovoy]

On ti, 17 huhti 2018, Garming Sam via samba-technical wrote:
> Hi,
> 
> I would have some reservations about using six. The last time I talked
> to Andrew, he felt quite strongly about the matter too. The overall
> summary of the concern is that we would be left at a half-way point
> which is neither purely-standard Python 2 nor Python 3 (as well as
> gaining the additional dependency on six). If the distros are as serious
> about dropping support for Python 2 as they claim, then having pure
> Python 3 would be preferable. The last thing I would want is a secondary
> effort required just to remove six as a dependency and rewrite it in
> Python 3 anyways.
Six helped us a lot in FreeIPA ports to Python3. We have to maintain
Python2/Python3 versions with a single code base and six has reduced the
amount of maintenance work dramatically.

$ cd freeipa
$ git grep -E '(import|from) six'|wc -l
390

FreeIPA's use of six is around following areas:
 - string and integer types (six.text_type, six.string_types,
   six.integer_types)
 - Python version detection (six.PY2 and six.PY3)
 - iterators (six.itervalues, six.iteritems, six.moves.zip)
 - addressing renames of modules (six.moves...)
 - metaclass programming (six.with_metaclass)

That's all. It allows us to have a version that works in RHEL and
Fedora (and Debian/Ubuntu once new 4.7 release is finally out).
 
> If the consensus really is to use six, at the very least I would propose
> that we use it in as constrained a way as possible. The straightforward
> renames and the example with urllib seem reasonable enough. On the other
> hand, using pretty much any of the six object model (or even syntax
> compatibility) does not seem like a particularly great idea in my view.
As you can see, apart from metaclass abstraction it is basically the
same for FreeIPA, just that we had already complex Python code base.
Samba Python code is not very Python idiomatic so in many cases it is
not about porting to Py2/Py3 compatible code but rather rewriting it in
a more Pythonic way which can reduce number of borrowed features from
six too.


> 
> (In regards to Gitlab, it needs to be added to the list of dependencies
> and then an image rebuilt).
> 
> Cheers,
> 
> Garming
> 
> On 17/04/18 04:01, Noel Power via samba-technical wrote:
> > Hi team,
> >
> > I like to start a discussion about the use of 'six' (a python2/3
> > compatability layer api) https://pythonhosted.org/six/
> >
> > Recently I have code across a couple of instances where I wanted to use
> > the 'six' library to port some samba python code to be python2/python3
> > compatible. Currently it is not possible to use 'six' as the CI machine
> > does not have it installed. I guess it is likely (I don't know) that the
> > autobuild machines also don't have it, does someone know ?
> >
> > What is the possibility of getting the 'six' library in place it the CI
> > (and/or) autobuild machines?
> >
> > For the moment my approach is to use the existing python/samba/compat.py
> > (currently not used) see attached patch [1] But.. I fear this is going
> > to become poor relation 'six' clone, my hope is using and extending this
> > is a temporary measure until we can kill it and replace it with six. The
> > transition from compat to six should be trivial e.g. and example of code
> > using the the existing content of the compat.py could be changed as follows
> >
> >   -from samba.compat import urllib_quote
> >   +from six.moves.urllib.parse import urllib_quote
> >
> > Thoughts?
> >
> > Noel
> >
> > [1] Note: not really looking for a review of this patch but rather the
> > issue of the missing 'six' However this is part of 
> > https://github.com/samba-team/samba/pull/161 :-)
> >
> 
> 

-- 
/ Alexander Bokovoy