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

Bits from the Debian PyCon Hangout



            === BITS FROM THE DEBIAN PYCON HANGOUT ===


    Agenda:

      - Discuss how we might support multiple interpreters with Python 3
        packages, for cpython + pypy C extensions.
      - Set up a plan for the svn => git migration
      - Python 2 "deprecation"
      - /usr/bin/python - what do?



CPYTHON + PYPY EXTENSIONS
-------------------------

   [APP]            <-- pypy Application
      \
 [python-foobar]    <-- Python extension
        \
   [python-barbaz]  <-- C extension


The issue is, how do we provide a module [python-barbaz], such that this
extension will work for application [APP], when [APP] is running under PyPy.
Since [APP] only (really) depends on [python-foobar], dragging the dependency
of something like [pypy-barbaz] to [APP]'s control is sub-optimal.

The first pass solution is to ship *both* cpython and pypy extensions in
[python-barbaz], but don't add a Dependency on `pypy`.

Another solution was to create a helper that crawls the depdencies of [APP],
and pull in Depends, on a package like [pypy-barbaz], and use those.

Consensus seems to be "give it a shot" and try to see what works.
There are no pypy apps, so this isn't an issue yet.

SVN => GIT
----------

        "We should just do it!"

We've settled on a deadline of Jessie release (yes, like 2 weeks!) to convert
the majority of packages *or* have a *very* clear plan. We need to also
make a patch system choice, and the deadline is the same.

The current primary patch systems for git are git-dpm and patch-queue. We'd
likely have to pick one of the two.

All present felt strongly that we should always use pristine upstream tarballs
as released by upstreams, with pristine-tar.


PYTHON 2 "DEPRECATION"
----------------------

Python 2 is EOL in 2020. Realistically, this means we have 2 cycles left to
get our packages off Python 2. This means we need to start planning *now* to
gut as much Python 2 from the archive as we can.

The end-goal is to get Python 2 off the default install ASAP, and make it so
hard to drag Python 2 in as a Dependency that you have to explicitly apt-get
install python 2.

    - Extend lintian to raise warnings if a package only supports Python 2.
        !! We need a contributor for this.

    - Research all packages whose upstream supports Python 3, but we only build
      Python 2 modules. File higher priority bugs to enable Python 3.

    - File wishlist bugs on things that only use Python 2. We'll use usertags
      to track progress.

    - Find applications which work in Python 3, and aggresively move them to
      Python 3, ensure Dependency chains are complete.

    - Look at Python 2 modules which contain no r-deps, mark them as canidates
      for removal. In 2 cycles time.

    - Look at packages that are Python 2 only and are dead upstream or have no
      support for Python 3 upstream. Patch packages to support alternatives,
      and remove the upstream dead Python 2 stuff before stretch.

    - Require new uploads supporting Python 3 upstream, to provide Python 3
      packages.

Next, we'll need to research what Debian infra currently uses Python 2. This
is going to be huge. We need to start to get the Debian Infra off Python 2 and
onto Python 3. There are some massive projects here, so this one might
be sticky.


/usr/bin/python
===============

    "This will be contentious"

Upstream Python's direction for Python paths is in favor of explicitly numbered
/usr/bin/python2 and /usr/bin/python3. In support of this, rough consensus in
the room is that /usr/bin/python should likely be removed *entirely* from
shebangs (though not from the distro).

/usr/bin/python2 exists as far back as wheezy, so there's no need to try to
fiddle around, even for oldoldstable backports.

Plans:

    - Explicitly define the shebang as being one of {python2,python3}
    - Add a lintian warning for files shipping /usr/bin/python.


geofft's suggestion was considered, consensus was to do such work upstream,
and formalize it as a PEP (or update an existing PEP).



Many thanks to Allison Randal, Asheesh Laroia, Barry Warsaw, Geoffrey Thomas,
Matthias Klose, and Stefano Rivera (I think that's everyone? Sorry if I missed
anyone!)


With love,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `-     http://people.debian.org/~paultag/conduct-statement.txt

Attachment: signature.asc
Description: Digital signature


Reply to: