On 4 December 2013 12:10, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 4 December 2013 20:41, Oscar Benjamin <oscar.j.benja...@gmail.com> wrote:
>>
>> Another possibility is that the pip/wheel/PyPI/metadata system can be
>> changed to allow a "variant" field for wheels/sdists. This was also
>> suggested in the same thread by Nick Coghlan:
>> https://mail.python.org/pipermail/distutils-sig/2013-August/022432.html
>>
>> The variant field could be used to upload multiple variants e.g.
>> 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
>> then if the user requests 'numpy:sse3' they will get the wheel with
>> sse3 support.
>
> That was what I was originally thinking for the variant field, but I
> later realised it makes more sense to treat the "variant" marker as
> part of the *platform* tag, rather than being an independent tag in
> its own right:
> https://bitbucket.org/pypa/pypi-metadata-formats/issue/15/enhance-the-platform-tag-definition-for
>
> Under that approach, pip would figure out all the variants that
> applied to the current system (with some default preference order
> between variants for platforms where one system may support multiple
> variants). Using the Linux distro variants (based on ID and RELEASE_ID
> in /etc/os-release) as an example rather than the Windows SSE
> variants, this might look like:
>
> cp33-cp33m-linux_x86_64_fedora_19
> cp33-cp33m-linux_x86_64_fedora
> cp33-cp33m-linux_x86_64
I find that a bit strange to look at since I expect it to be like a
taxonomic hierarchy like so:
cp33-cp33m-linux
cp33-cp33m-linux_fedora
cp33-cp33m-linux_fedora_19
cp33-cp33m-linux_fedora_19_x86_64
Really you always need the architecture information though so
cp33-cp33m-linux_x86_64
cp33-cp33m-linux_fedora_x86_64
cp33-cp33m-linux_fedora_19_x86_64
> The Windows SSE variants might look like:
>
> cp33-cp33m-win32_sse3
> cp33-cp33m-win32_sse2
> cp33-cp33m-win32_sse
> cp33-cp33m-win32
I would have thought something like:
cp33-cp33m-win32
cp33-cp33m-win32_nt
cp33-cp33m-win32_nt_vista
cp33-cp33m-win32_nt_vista_sp2
Also CPU information isn't hierarchical, so what happens when e.g.
pyfftw wants to ship wheels with and without MMX instructions?
>> I think it would be good to work out a way of doing this with e.g. a
>> cpuinfo package. Many other packages beyond numpy could make good use
>> of that metadata if it were available. Similarly having an extensible
>> mechanism for selecting wheels based on additional information about
>> the user's system could be used for many more things than just CPU
>> architectures.
>
> Yes, the lack of extensibility is the one concern I have with baking
> the CPU SSE info into the platform tag. On the other hand, the CPU
> architecture info is already in there, so appending the vectorisation
> support isn't an obviously bad idea, is orthogonal to the
> "python.expects" consistency enforcement metadata and would cover the
> NumPy use case, which is the one we really care about at this point.
An extensible solution would be a big win. Maybe there should be an
explicit metadata option that says "to get this piece of metadata you
should install the following package and then run this command
(without elevated privileges?)".
Oscar
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
