On Mon, Sep 17, 2018, 18:51 Joni Orponen <j.orpo...@4teamwork.ch> wrote:
> On Mon, Sep 17, 2018 at 6:07 PM Antoine Pitrou <anto...@python.org> wrote: > >> Paul Moore wrote: >> > I'm not really familiar with manylinux1, but I'd be concerned if we >> > started getting bug reports on pip because we installed a library that >> > claimed to be manylinux1 and was failing because it wasn't. (And yes, >> > packaging errors like this are a common source of pip bug reports). >> > >> > It seems to me that it's defeating the purpose of having standards if >> > people aren't willing to follow them... >> >> I agree with that. OTOH it seems providing binary wheels is generally a >> strong >> demand from the community. I would be fine with only providing conda >> packages myself. >> > > The biggest demand seems to be for developer convenience of quick > downloads / installs and by people whom have not delved very deep into the > gnarly black arts of cross compilation and forwards / backwards > compatibility maintenance. > > Deployment bandwidth costs and install times are a second tier use, but > still a real concern to any parties whom should consider sponsoring any > effort going towards solving anything within the scope, as solving their > gripes would save them money. > > By the way other packages are already doing worse: >> https://github.com/tensorflow/tensorflow/issues/8802 >> > > Domain specific packages with real industry needs will need to deviate > from any standard put forth as the world of the bleeding edge moves faster > than the standards can. > > What a lot of packages would actually need, is to have per operating > system per distro per distro version wheels, but that'd get quite insane > quick and put a lot of effort onto the package maintainers or the > maintainers of the manylinux-esque build containers. > I'm doubtful that there are many packages that "need" this. People don't do this on Windows or macOS, and those platforms seem to do ok. Still we should have some way to describe such packages, so tensorflow can at least have be accurate metadata, and for a variety of other use cases (Alpine, arm, conda, etc.). > And even something like that will still spectacularly fall apart on macOS > by stuff like building against 3rd party libraries from macports vs. fink > vs. homebrew installed into /usr/local/ vs. homebrew installed into > $HOME/.homebrew varying between the unsuspecting package maintainer / wheel > builder and the end users of the wheel. > This isn't really an issue. Whatever libraries you need should be vendored into the wheel with a tool like 'delocate', and then it doesn't matter what third-party package manager your end users do or don't use. > Oddly enough this seems to be by far the least problematic on Windows. > There's no real difference between Windows/macOS/Linux in terms of binary compatibility. On Windows people are more used to shipping everything with their package, that's all. If you do the same thing on macOS and Linux, it works great. -n
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/A47YBCTWPH4ST45JJP4CXD6SSIZNOVNP/
