Fw: [PROPOSAL] To retire autoconf for 4.1

[Simo]

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.


>>>> Unfortunately we cannot just make a full switch. Because there are
>>>> distributions that will stay on Python 2.x for a long time, much
>>>> longer than Fedora's support for Python 2.x presumably.
>>>>
>>>> So we should really look into what it will take to try to support
>>>> both 2.x and 3.x especially for generated bindings as the binding
>>>> interface, I am told, changes quite some fundamental things.
>>>>
>>>> A flag day where we switch fro 2 to 3 is highly unfeasible unless we
>>>> also decide to drop support for all Enterprise Linux distributions
>>>> and all other long term maintenance Unix flavors at the same time. I
>>>> do not think that would be a wise choice.
>>> 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.

>>> 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 ?

Simo.