Fw: [PROPOSAL] To retire autoconf for 4.1

[Jelmer Vernooij]

On Fri, May 24, 2013 at 11:52:43AM -0400, Simo wrote:
> On 05/24/2013 10:48 AM, Jelmer Vernooij wrote:
> >On Fri, May 24, 2013 at 09:58:56AM -0400, Simo wrote:
> >>On 05/24/2013 09:07 AM, Jelmer Vernooij wrote:
> >>>On Fri, May 24, 2013 at 08:30:10AM -0400, Simo wrote:
> >>>>On 05/24/2013 07:58 AM, yaberger at ca.ibm.com wrote:
> >>>>>http://wiki.python.org/moin/Python2orPython3
> >>>>>
> >>>>>I believe you're right, ie: when most major distributions will provide a
> >>>>>Python 3.x package in their repositories, Samba team should start working
> >>>>>on moving from Python 2.x to 3.x for Samba and Waf.
> >>>>>RHEL 6.4 is on 2.6.6
> >>>>>Debian 7 is on 2.7.3 but also have a package for Python 3.2.3
> >>>>At SambaXP I and Alexander started raising a concern about this.
> >>>>Fedora is starting to plan to move to Python 3, so we need to start
> >>>>thinking about moving samba as well.
> >>>When will Fedora drop support for Python 2.x? Just having the default changed
> >>>shouldn't be a problem, so long as Python2.x is still installable.
> >>It is not that simple. Samba now is in the business of providing
> >>bindings, that mean dependencies for other applications. It is very
> >>likely we'll have to build bindings for both 2.x and 3.x at the same
> >>time and make them parallel installable for a while. Otherwise it
> >>becomes a multipackage flag day where all of samba and all dependent
> >>packages need to switch at once.
> >Are there particular dependent packages you are referring to here?
> >What exactly do we promise external users can rely on? Just tdb and ldb?
> >
> >We need to clarify what exactly external users can expect from our APIs
> >and changes to them. In 3.x the answer to this was just that everything in
> >"libsmbclient.h" was public, but with Python APIs in Samba 4 it's more
> >complicated.
> 
> We use the python binding for dcerpc and related stuff in FreeIPA
> for example.
> I'll let Alexander give a list, as he was the one that did the
> research and started using the bindings.
Assuming that's all you need, I suspect supporting those for both versions
is a lot more achievable than blanket support of all our Python code on
both 2.x and 3.x.

To manage expectations, I still think it would be good if we clarified what
we do and don't plan on doing with regard to the external use of various Python
APIs.

> >>>I've tried to do support for both python2 and python3 with a few projects. It
> >>>requires ugly hacks that make the code less readable, is a major pain to keep
> >>>up and prone to regressions even for smaller projects. It would be
> >>>a nightmare for a project the size of Samba.
> >>Blame python developers, 2 -> 3 *will* be nasty and hard for a lot
> >>of projects, we are not alone.
> >I agree, see my other email. Python upstream has done a bad job
> >of managing this transition, and it shows in the number of packages
> >that have migrated so far. There is a chicken-egg problem; distributions won't
> >drop python2 until most packages have migrated to Python3, but packages won't
> >migrate while the rest of the ecosystem is still on Python 2.
> >
> >There is no urgency for Samba to migrate so long as Python 2 is widely
> >available. It would still be nice to - a less fragmented ecosystem
> >is good for everybody, and there are some nice features in Python 3 -
> >but we need to consider the associated costs as well.
> 
> There is no urgency indeed, but we should start making plans on how
> to address the migration.
> It will happen at some point and because handling both Python 2 and
> Python 3 at the same time is painful if we ever reach critical mass
> on Python 3 then packages may rapidly start dropping v2 support and
> force fast paced distributions hands into trying to move wholesale
> to Python 3.
> 
> We do not want to have to rush then.
I agree. Being prepared is never a bad idea. :-)

> >>>What are the long term releases we should be worried about a year from now that
> >>>don't support Python3 yet? Debian oldstable and stable both have Python3, and
> >>>all LTS releases of Ubuntu that are still supported also have a version of
> >>>Python3.
> >>No RHEL so far has Python 3, but see above, even if RHEL has python
> >>3 it wouldn't make a big difference we would still wan to build with
> >>python 2 due to the fact the samba bindings are now dependencies for
> >>other projects.
> >Is that a burden that should be with the upstream Samba project?
> >
> >Maintaining support for both versions takes (a significant chunk of) developer
> >resources that could be used for other things.
> >
> 
> True, so my question is, given most of the bindings are partially
> autogenerated, is there a way we can reduce the developer pain by
> using some abstraction perhaps ?
The DCE/RPC bindings are almost entirely generated. There are a lot of other
bindings written in C that are not, but it sounds like you guys don't actually
need those?

So in summary, if there is a small subset you need to be available for both
Python 2.x and 3.x then that is a lot more achievable than making everything
available for both - and considering the code you are using is probably more stable
and less prone to changes, there will probably also be less friction in keeping
it working with both.

Cheers,

Jelmer