[PATCHES] Build pytalloc for two Python versions at once, port to py3

[Jelmer Vernooij]

On Mon, Mar 02, 2015 at 12:09:25PM +0100, Petr Viktorin wrote:
> On 02/26/2015 11:36 PM, Andrew Bartlett wrote:
> >On Thu, 2015-02-26 at 12:23 +0100, Petr Viktorin wrote:
> >>On 02/25/2015 07:53 PM, Andrew Bartlett wrote:
> >>I'd really like to have the buildsystem changes vetted before I tackle
> >>the split, so I (and also the future reviewers) can focus on the porting
> >>itself.
> >
> >That's understandable.  I'm hoping Jelmer might post some thoughts.  He
> >and I came up with a reasonable set of expectations in some private
> >mails going back and forth on this.
> 
> I'm quite interested in these thoughts. The last time we discussed this on
> the list, I got the impression that there was general agreement that the
> standalone libraries (like talloc) could be ported before the rest of Samba,
> supporting both versions of Python for a while.
> If there are other expectations floating around in private, I would really
> like to hear them.

I think it would be reasonable to support both Python 2 and Python 3
in the standalone libraries for some time, especially since they are used
by a more projets than just Samba.

These Python modules are also fairly small, they have relatively many tests
and the overhead of supporting two Python versions is limited. To
prevent regressions, we should build with both versions on the
buildfarm and be able to build simultaneously against both versions
(to make life easy on both Samba developers and packagers). Because of
some of the new features to ease portability, it would be nice if we
could require Python3 >= 3.4.

As for the Samba Python modules, the balance is different there. Samba
has *a lot* more Python code and C Python bindings. There are fewer
unit tests for that code but many more integration tests for Samba
overall. We don't want "make test" to run the entire testsuite twice,
once with each Python version, and on top of that we are less
likely to catch Python compatibility issues just by running the Python
module unit tests.

There are also fewer external users of the Samba Python modules; at
this point I'm only aware of OpenChange and FreeIPA.

It would require a non-trivial extra amount of effort on part of the Samba
developers to maintain support for two Python versions; see the
earlier thread for a more detailed of why I think supporting two
Python versions would require extra resources and why I think this is
not worth it.

That said, if somebody wants to put the effort in to port Samba to
another major Python version (e.g.: 3), I would like to accomodate
them if possible. However, such an effort should minimize the burden
on the rest of Samba development. I would suggest the following
constraints on support for additional major Python versions:

 * It shouldn't clutter the code with lots of compatibility wrappers
   that make the code unreadable.
 * Samba officially supports only a single major python version,
   the others are only supported on a best-effort basis and by
   the people that care about them.
 * Other Samba developers should be able to develop against a single
   major Python version without having to worry about breaking
   other major Python versions, or being responsible for keeping
   Samba working with any major Python versions but the default
   one (Python 2 at the moment).

Cheers,

Jelmer
-- 
Jelmer Vernooij <jelmer at samba.org>