> And in any case we have lots of users who don't use conda and are thus doomed to support both ecosystems regardless, so we might as well make the best of it :-).
Yes, this is the key. Conda is a great tool for a lot of users / use cases, but it's not for everyone. Anyways, I think I've made a pretty good start on the tooling for a wheel ABI tag for a LSB-style base system that represents a common set of shared libraries and symbols versions provided by "many" linuxes (previously discussed by Nathaniel here: https://code.activestate.com/lists/python-distutils-sig/26272/) -Robert On Mon, Jan 11, 2016 at 5:29 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Jan 11, 2016 3:54 PM, "Chris Barker" <chris.bar...@noaa.gov> wrote: > > > > On Mon, Jan 11, 2016 at 11:02 AM, David Cournapeau <courn...@gmail.com> > wrote: > >>> > >>> If we get all that worked out, we still haven't made any progress > toward the non-standard libs that aren't python. This is the big "scipy > problem" -- fortran, BLAS, hdf, ad infinitum. > >>> > >>> I argued for years that we could build binary wheels that hold each of > these, and other python packages could depend on them, but pypa never > seemed to like that idea. > >> > >> > >> I don't think that's an accurate statement. There are issues to solve > around this, but I did not encounter push back, either on the ML or face to > face w/ various pypa members at Pycon, etc... There may be push backs for a > particular detail, but making "pip install scipy" or "pip install > matplotlib" a reality on every platform is something everybody agrees o > > > > > > sure, everyone wants that. But when it gets deeper, they don't want to > have a bunc hof pip-installable binary wheels that are simply clibs > re-packaged as a dependency. And, then you have the problelm of those being > "binary wheel" dependencies, rather than "package" dependencies. > > > > e.g.: > > > > this particular build of pillow depends on the libpng and libjpeg > wheels, but the Pillow package, in general, does not. And you would have > different dependencies on Windows, and OS-X, and Linux. > > > > pip/wheel simply was not designed for that, and I didn't get any warm > and fuzzy feelings from dist-utils sig that the it ever would. And again, > then you are re-designing conda. > > I agree that talking about such things on distutils-sig tends to elicit a > certain amount of puzzled incomprehension, but I don't think it matters -- > wheels already have everything you need to support this. E.g. wheels for > different platforms can trivially have different dependencies. (They even > go to some lengths to make sure this is possible for pure python packages > where the same wheel can be used on multiple platforms.) When distributing > a library-in-a-wheel then you need a little bit of hackishness to make sure > the runtime loader can find the library, which conda would otherwise handle > for you, but AFAICT it's like 10 lines of code or something. > > And in any case we have lots of users who don't use conda and are thus > doomed to support both ecosystems regardless, so we might as well make the > best of it :-). > > -n > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
