[Distutils] What does it mean for Python to "bundle pip"?

Nick Coghlan ncoghlan at gmail.com
Fri Aug 23 09:40:09 CEST 2013

On 23 August 2013 16:31, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> On 23 Aug, 2013, at 5:17, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> That said, I'm considering the idea of adding a "variant" field to the
>> compatibility tags for wheel 1.1, along the lines of what Oscar
>> Benjamin suggested earlier. By default, installers would only find
>> wheels without a variant defined, but users could opt in to looking
>> for particular variants. The meaning of the variants field would be
>> entirely distribution specific. Numpy, for example, could publish:
>> numpy-1.7.1-cp27-cp22m-win32.whl
>> numpy-1.7.1-cp27-cp22m-win32-sse.whl
>> numpy-1.7.1-cp27-cp22m-win32-sse2.whl
>> numpy-1.7.1-cp27-cp22m-win32-sse3.whl
>> The only restrictions on the variant tags would be:
>> 1. must be ASCII
>> 2. must not contain '.' or '-' characters
>> You could even go to the extent of using hashes as variant tags.
> Is adding variants necessary? Numpy use runtime selection for picking
> the most appropriate extension code (heck, AFAIK recent versions of GCC
> can even compile multiple variants of functions and pick the right one
> automaticly).

No, I'm not sure the variant system is necessary. It is almost
certainly acceptable to constrain people to offering at most one
binary per platform per Python interpreter per Python version for the
wheel ecosystem, and suggest they use something hash based like conda
if they need finer granularity than that.

If we *did* add that flexibility to wheels, though, then the variant
system is how I would do it. It would just be an arbitrary labelling
mechanism that allowed users to say "give me this variant rather than
the default one", not anything actually automated or necessarily
reflecting an underlying system capability.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list