On Thursday, April 30, 2020 5:49:20 PM EDT Stefano Rivera wrote: > 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. Well, we have also talked about pypy vendoring as much of the python2.7 package as it needs to build itself so we don't have to support it in the archive as an active interpreter, but that's a different discussion. > > 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. I haven't really tested that yet, so I don't doubt that. It was an assumption. My first run at virtualenv ran aground on trying to have different package lists depending on if the install invoked --download or not (since a --download install with the upstream pip doesn't need all the unvendored wheels). So that's something to sort later. We'll want to document how to do it even if we get a working solution that doesn't require it. > > > 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. So far setuptools is the only one. It might pick up though now that they've done it. We've split packages into a source for python2 and a source for python3 in a number of cases, so I think this scales reasonably. We can just yank all the python2 sources the same time pip drops python2 or we do. > > 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. Let's focus on 2.1a so we don't have to have that argument ... I might actually have a little time tomorrow to work on it. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.