Re: Bits from the Debian PyCon Hangout
On April 14, 2015 6:01:56 PM EDT, Paul Tagliamonte <paultag@debian.org> wrote:
>
> === 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.
What is the "it" that's to be given a shot? I see two choices there? Did you discuss the package size implications of embedding the pypy extension in the python-foo binary?
>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"
I'm more confused than angry ...
>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).
Unless we are also removing /usr/bin/python, why does this matter? Unless there will be cases where /usr/bin/python2 exists while /usr/bin/python doesn't, I don't see what this does?
>/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.
As above, what's the benefit of this.
>
>geofft's suggestion was considered, consensus was to do such work
>upstream,
>and formalize it as a PEP (or update an existing PEP).
>
I think formalizing the eventual demise of /usr/bin/python would be a good idea.
>
>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!)
Yes, thanks.
Scott K
Reply to: