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: "numpy|mkl" and "numpy|openblas" 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. -Chris -- Christopher Barker, Ph.D. Oceanographer 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.bar...@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
