Re: wheel support for Debian?
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.
> - 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
Reply to: