On April 14, 2015 6:01:56 PM EDT, Paul Tagliamonte <paul...@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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/93a2c368-8cee-441c-b130-b57215864...@kitterman.com