On Thursday, April 30, 2020 6:21:48 PM EDT Scott Kitterman wrote: > 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. This is done and in PAPT git for dirtbike. Improvements welcome. It works, but isn't pretty in some cases. For now, we can provide a universal wheel for setuptools and pkg_resources from the python-* variant packages, so a policy change isn't urgent. Given the method dirtbike is going to use, it would be trivial to have py3 only wheels for them as well. I think that is preferable since it would allow python3 users the benefits of the newer releases, so I still think the policy change is a good idea, but since it is less urgent than when I originally wrote, I'm not pushing for a new upload of the policy. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.