Path: csiph.com!3.eu.feeder.erje.net!feeder.erje.net!news.albasani.net!tahina.priv.at!bofh.it!news.nic.it!robomod
From: Stefano Rivera <stefanor@debian.org>
Newsgroups: linux.debian.maint.python
Subject: Re: Python Wheel Related Policy Change
Date: Thu, 30 Apr 2020 23:50:02 +0200
Message-ID: <A1pea-38B-5@gated-at.bofh.it>
References: <A183E-11c-5@gated-at.bofh.it> <A1kev-a3-37@gated-at.bofh.it> <A1mgi-1nf-23@gated-at.bofh.it> <A1o8q-2w2-7@gated-at.bofh.it>
Old-Return-Path: <stefano@rivera.za.net>
Mail-Followup-To: Scott Kitterman <debian@kitterman.com>, debian-python@lists.debian.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: NeoMutt/20180716
Approved: robomod@news.nic.it
Lines: 85
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.python:12546

Hi Scott (2020.04.30_20:33:59_+0000)
> > That seems reasonable, although if we're going down that road, it
> > probably makes no sense for any of them to be universal.
>=20
> If we were talking about maintaining this for multiple release cycles wit=
h=20
> lots of version divergence, I would agree.  Let's not do more than we hav=
e to=20
> until python2 is gone (whether it is before bullseye or after).

I suspect pypy (2.7) will probably be around post-bullseye, unless
somebody funds pypy to migrate rpython to python 3.

But yeah, we can change strategy later, if appropriate.

> As a result, one could add some kind of py2 flag to dirtbike to tell it t=
o look=20
> in /usr/lib/python2.7/dist-packages and make a 'universal' wheel from the=
re. =20
> It could then rename the files from py2.py3-none-any.whl to py2-none-any.=
whl. =20
> The bonus Tag in the WHEEL file shouldn't hurt anything.
>
> They key is I think we can do this without actually running python2, we j=
ust=20
> need to be able to install python-setuptools/pkg-resources.  That should =
be=20
> supportable ~as long as python2.7 is in the archive.

Yep, that sounds good.

> Agreed.  As long as pip supports python2, we should try.  Worst case we c=
an=20
> tell people to find their own interpreter and do a --download install wit=
h=20
> setuptools pinned to 44.0.0 (that approach doesn't need ipaddr because th=
ey'll=20
> get the upstream pip in the virtualenv too. =20

When we get to the download route: pip can parse Requires-Python, and it
looks like virtualenv uses the system pip to download pip, so the
pinning shouldn't be necessary, I think.

> > So, the options are:
> > 1. pin pip dependencies at versions that support py2, forever. Obviously
> >    this is a no-go.
> > 2. Ship py2 and py3 wheels.
> >    2.1. package the py2 weels with dirtbike. This requires bringing back
> >         python-wheel, or more work on dirtbike.
> >    2.2. Ship static py2 wheels (like we did pre-dirtbike). It's not like
> >         upstream is continuing development...
> > 3. Let virtualenv always download pip from pypi for py2. Only ship py3
> >    wheels.
> >=20
> > The easy options here are 2.2 and 3.
>=20
> 2.1a Where needed package 'py2' wheels with dirtbike running python3.

Ah, yeah.

Still requires keeping py2 source packages whenever a library in the pip
dependency stack drops py2 support. But if they move slowly, that's
fine.

> 2.2 is using sourceless binaries, so I think it's got DFSG issues.  We ne=
ed=20
> the preferred form of modification and a bdist_wheel is not that.

They could be bdist_wheeled at build time, within a single source
package.

> I think 2.1a would be nice if someone can manage it.  We'll need to suppo=
rt 3=20
> eventually.  I plan to implement 3 as an option when I upload pip 20.1 an=
d=20
> virtualenv 2.0.18.

Not necessarily. 2.2 is equivalent to 3, but without hitting PyPI.

SR

--=20
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272