On May 15, 2014, at 6:32 PM, Barry Warsaw <ba...@debian.org> wrote: > My thoughts... > > On May 16, 2014, at 12:07 AM, Matthias Klose wrote: > >> - should we add wheels everywhere? I don't think we should, >> but I'd like to state this somewhere, like in the python policy. > > Agreed, we should not add wheels everywhere. I would like to keep it very > limited to exactly the (small) set of packages we need to devendorize > ensurepip, recursively. If some other devendorizing task in the future > requires the use of wheels, then we have a framework in place, but I would > like to actively discourage their use. > > I do plan to propose an update to policy stating this, but I haven't gotten to > that yet. I will of course post the proposed update here first. > >> - where to put wheels? /usr/share/python-wheels is an ad-hoc >> decision which was never proposed. I'm aware about "universal" >> wheels but I'd like to clarify where wheels should be located. >> Do we need /usr/share/python/wheels, and/or /usr/share/python3/wheels? > > I proposed /usr/share/python-wheels here: > > https://lists.debian.org/debian-python/2014/05/msg00025.html > > but it's a detail that was probably easily lost in the wall of text. I didn't > see any objections to that specifically though. We could change it if > something clearly better is proposed, although it would necessitate some new > uploads and updated quilt patches. > > For the current use case, we only need pure-Python wheels, and in fact Python > can't currently import extension modules from zips, so architecture dependent > wheels wouldn't work anyway. Universal wheels (Python 2 and 3 compatible) are > used because that's what the ensurepip machinery already uses. it's just as > easy to create universal wheels, and all the packages we currently care about > *are* bilingual, so using them here reduces the upstream delta. Since I don't > view the building of wheel packages as general purpose, I think it's fine to > just put them in a shared directory. > > In other words, non-universal wheels YAGNI.
For the record since it’s pip that this is for, we have no plans to ever include something that won’t work with a universal Wheel. Our requirements for us to depend on something is 2.6, 2.7, 3.2+ with single source and pure Python. > >> - naming of wheel packages. It's good to see wheels packaged >> in a separate binary package. However there is no proposal >> how to name these packages. > > That was also proposed in the above referenced message. Suggestions welcome, > but I think python-foo-wheels is as good as anything (it's pretty > self-descriptive ;). > > Cheers, > -Barry > > > -- > 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/20140515183201.6acc4...@anarchist.wooz.org > ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail