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. > > If we were talking about maintaining this for multiple release cycles with > lots of version divergence, I would agree. Let's not do more than we have to > 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 to > look > in /usr/lib/python2.7/dist-packages and make a 'universal' wheel from there. > It could then rename the files from py2.py3-none-any.whl to py2-none-any.whl. > > 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 just > need to be able to install python-setuptools/pkg-resources. That should be > 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 can > tell people to find their own interpreter and do a --download install with > setuptools pinned to 44.0.0 (that approach doesn't need ipaddr because > they'll > get the upstream pip in the virtualenv too. 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. > > > > The easy options here are 2.2 and 3. > > 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 need > 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 support 3 > eventually. I plan to implement 3 as an option when I upload pip 20.1 and > virtualenv 2.0.18. Not necessarily. 2.2 is equivalent to 3, but without hitting PyPI. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
