[Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

[Oscar Benjamin]

On Wed, 7 Oct 2015 19:42 Donald Stufft <donald at stufft.io> wrote:

On October 7, 2015 at 2:31:03 PM, Oscar Benjamin (oscar.j.benjamin at gmail.com)
wrote:
> >
> Your idea of an sdist as something that has fully static build/runtime
> dependency metadata and a one to one correspondence with binary
> wheels is not a usable format when releasing the code for e.g.
> numpy 1.10. It's fine to say that pip/PyPI should work with the
> source in some other distribution format and numpy could produce
> that but it means that the standard tarball release needs to be
> supported some how separately. Numpy should be able to use PyPI
> in order to host the tarball even if pip ignores the file.
>
>
> If numpy released only source wheels then there would be more
> than one source wheel for each release corresponding to e.g.
> the different ways that numpy is linked. There still needs to
> be a way to release a single file representing the code for the
> release as a whole.
>

Can you expand on this please? I've never used numpy for anything serious
and
I'm trying to figure out why and what parts of what I'm thinking of wouldn't
work for it.



Currently I can take the code from the numpy release and compile it in
different incompatible ways. For example I could make a wheel that bundles
a BLAS library. Or I could make a wheel that expects to use a system BLAS
library that should be installed separately somehow or I could build a
wheel against pyopenblas and make a wheel that depends on pyopenblas. Or I
could link a BLAS library statically into numpy.

A numpy release supports being compiled and linked in many different ways
and will continue to do so regardless of any decisions made by PYPA. What
that means is that there is not a one to one correspondence between a numpy
release and a binary wheel. If there must be a one to one correspondence
between a source wheel and a binary wheel then it follows that there cannot
be a one to one correspondence between the source release and a source
wheel.

Of course numpy could say that they will only upload one particular source
wheel and binary wheel to PyPI but people need to be able to use the source
release in many different ways. So only releasing a source wheel that maps
one to one to a particular way of compiling numpy is not an acceptable way
for numpy to release its code.

--
Oscar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151007/0ecb6769/attachment-0001.html>