[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: wheel support for Debian?



On Thursday, May 15, 2014 18:32:01 Barry Warsaw 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.
> 
> > - 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

Shouldn't it be singular?  Each package provides a wheel, not several wheels 
(and I'd name the location the same for consistency).

Scott K


Reply to: