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

Chris Barker chris.barker at noaa.gov
Fri Oct 9 19:04:00 CEST 2015

I"ve been following this thread and gotten a bit lost. But I do care,
because I'm a heavy numpy user, and also because I was involved for years
in building pacakges for OS-X, and currently need distribute some of my own
stuff that has semi-ugly C lib dependencies (Not as ugly as BLAS.,though
:-) )

In the last couple years I gave up on PyPi and pip (and went with Anaconda
and conda)-- that ecosystem simply doesn't currently support my use-cases.
But it would be nice to go back, and it looks like there are some idea on
the table that will make that possible.

But could someone clarify a thing or two for me??

1) what in the world is a "source wheel"? And how is it different than an
sdist (other than maybe in a different file format.

2) Is it indeed "OK" with the current PEPs and tools for different binary
wheels to have different dependencies? This would be the example of, for
instance the Matplotlib binary wheel for Windows depends on a py_zlib,
whereas the binary wheel for OS-X relies on the the system lib, and
therefor does not have that dependency?
 (and has anyone worked out the linking issues so that that would all work
with virtualenv and friends...)

if (2) then it seems the issue is what to do with the same package on the
same platform having potentially different dependencies -- i.e. numpy w/
mkl and numpy w/some_other_blas. In that case, I think that this could
completely explode into m**n possible wheels if we try to accommodate it in
a fully flexible manner -- so making it a name-thing (like was proposed
here), makes sense to me -- numpy_mkl and numpy_openblas are, as far as pip
is concerned, different packages. I think this is OK, as we probably only
want some small subset of possible build up on PyPi anyway (only one?).

But it does get a bit tricky if you want to put up a package that depends
on "pure" numpy -- i.e. it doesn't care which BLAS the numpy it uses, but
it DOES need numpy.

This could this be Accomidated byt have an "or" option for dependencies:

numpy_mkl>=1.9 or numpy_openblas >= 1.9

However, that would mean that the author of that wheel would need to know
all of the wheels that might be available up front - less than ideal.

Which seems to point more to having an optional "binary_build" component to
the name. Not sure what syntax is available, but the idea would be that:




would both match "numpy"

which, of course would require changes to the whole stack...

and off the top of my head, I'm wondering whether having one "binary_build'
flag would be enough, or if we'd find that we wanted n options, and n*m
combinations, and this would all blow up.



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151009/8e2fd266/attachment.html>

More information about the Distutils-SIG mailing list