[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python 2, Python 3, Stretch & Buster



On Thu, Apr 16, 2015 at 09:50:02AM -0400, Paul Tagliamonte wrote:

>     - If *you* maintain or work on a Python 2 project that's used in Debian
>       Development (buildd, release tools, QA tools, ftpteam tools), please
>       email me a link to the project. An accurate census will help hugely. If
>       it works on Python 2, Python 2 and Python 3 or just Python 3, you should
>       include those details as well.

Hi. I welcome, in principle, migrations to python3. I like python3.4 more
than python2, both the language and the stdlib it comes with.

This is a census of the services I'm maintaining, more comments will
come after the census:

<census>

nm.debian.org: currently python2 only.

  dependencies outside stdlib:
    python-debiancontributors
    django 1.7
    python-django-housekeeping
    ldap
    markdown
    psycopg2
    sqlite3
    xapian
    fabric
    python-django-ratelimit
    model_mommy

contributors.debian.org: currently python2 only.

  dependencies outside stdlib:
    python-debiancontributors
    django 1.7
    python-django-housekeeping
    fabric

debtags.debian.net: currently python2 only.

  dependencies outside stdlib:
    django 1.7
    python-django-housekeeping
    xapian
    fabric
    python-debian

sso.debian.org: currently python2 only.

  dependencies outside stdlib:
    django 1.7
    fabric
    python-requests
    django-cors-headers
    django-oauth-toolkit

python-debiancontributors: currently python2 only.

  dependencies outside stdlib:
    python-requests
    psycopg2
    looking at python-git for future developments

python-django-housekeeping: currently python2 only.

  only depends on django and stdlib

for nm.d.o, contributors.d.o, sso.d.o, python-debiancontributors and
python-django-housekeeping,  most of the code already looks at python3
and uses these future imports:

  from __future__ import absolute_import
  from __future__ import division
  from __future__ import print_function
  from __future__ import unicode_literals

debtags.debian.net is older code and may need more porting efforts.

</census>

HOWEVER. I am the only person currently looking after all that code, and
my development time on it is mostly spent fixing bugs and implementing
the features that make it useful. See for example [1] and [2] for the
kind of things that are on top of my todo list.

So, I would welcome help. However, I still have nightmares from the
time of active 2.x development, where at every 2.x python upgrade some
bits of my code started spitting deprecation warnings or stopped
working, and I had to take a day off work to rush into a very unpleasant
emergency forward port, tracking down arbitrary API breakages caused by
someone with commit rights to the python stdlib who had a different
concept of "obscure" than me[3].

At the moment, I have a strong guarantee from the python core developers
that my code WILL keep working until 2020, and I will NOT have that
guarantee if I migrate to python 3. I would laugh at this, if it didn't
make me cry first. See my comments at [4].

So, if I am left to my own devices, I will *not* consider any porting
effort until late 2019, to make sure that between here and 2020 I will
need to do porting only once from 2 to 3, instead of who knows how many
times from 2.x to 3.4, then from 3.x to 3.x+n at every new Debian stable
release.

With help (i.e. with people doing the porting work, who I'm happy to
assist), I'm glad to migrate to python 3. But help MUST come also with
someone taking responsibility for guaranteeing that they will ALSO do
the porting work in the future, chasing whatever will break with new 3.x
versions.

That is a tricky guarantee to make from my point of view, because it has
already happened that at first there was a committed group, and then at
some point things broke, everyone was busy, my ass was the only one on
the line, and I ended up having to take time (two /weeks/ in one
occasion) off paid work for emergency remediation.

I have a massive amount of stable code deployed, and it *is* being used.
In my experience this is a use case that the python core developers are
not taking much into account[5], so I'm playing defensive until I see a
strong sign that that attitude has changed.


[1] https://lists.debian.org/debian-project/2015/04/msg00035.html
[2] https://lists.debian.org/debian-project/2015/04/msg00036.html
[3] Mine is something along the lines of: "it's not obscure of it is
    documented". It sounds crazy, I know.
[4] http://lwn.net/Articles/640179/
[5] this would also be funny, it it didn't mean that it creates an
    ecosystem that encourages experimentation but discourages success.
    I suggest reading http://lesswrong.com/lw/9o/stuck_in_the_middle_with_bruce/
    and the actual story it links, as I think it describes exactly that
    kind of pattern.


Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

Attachment: signature.asc
Description: Digital signature


Reply to: