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

[Oscar Benjamin]

On 21 August 2013 08:04, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Oscar Benjamin <oscar.j.benjamin <at> gmail.com> writes:
>
>> I think that they are responsible for installing the f2py script in
>> each of my Scripts directories. I never use this script and I don't
>> know what numpy wants with it (my understanding is that the Fortran
>> parts of numpy were all shifted over to scipy).
>
> IIUC, if a third-party extension wants to use Fortran, the build process
> converts it using f2py in to a Python-importable extension. It may be a
> feature for distributions that use numpy, even if numpy doesn't use Fortran
> itself.

Okay, that makes sense. I'm sure that's not a big problem. It won't
work very well on Windows (the case where wheels are really needed)
anyway since it doesn't have a wrapper script and won't get picked up
by make etc.

>> > 2. Tags (not in general, but AIUI numpy distribute a fancy installer that
>> > decides what compiled code to use depending on whether you have certain CPU
>> > features - they may want to retain that, and to do so may prefer to have
>> > more fine-grained tags, which in turn may or may not be possible to
>> > support). I don't think that's a critical issue though.
>>
>> I guess this is what you mean:
>> https://github.com/numpy/numpy/blob/master/tools/win32build/cpuid/test.c
>>
>> Is there no way for them to run a post-install script when pip
>> installing wheels from PyPI?
>
> I'm not sure that would be enough. The numpy installation checks for various
> features available at build time, and then writes numpy source code which is
> then installed. When building and installing on the same machine, perhaps no
> problem - but there could be problems when installation happens on a
> different machine, since the sources written to the wheel at build time
> would encode information about the build environment which may not be valid
> in the installation environment.
>
> ISTM for numpy to work with wheels, all of this logic would need to move
> from build time to run time, but I don't know how pervasive the
> source-writing approach is and how much work would be entailed in switching
> over to run-time adaptation to the environment.

I may have misunderstood it but looking at this
https://github.com/numpy/numpy/blob/master/tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in#L147
I think that the installer ships variants for each architecture and
decides at install time which to place on the target system. If that's
the case then would it be possible for a wheel to ship all variants so
that a post-install script could sort it out (rename/delete) after the
wheel is installed?


Oscar