I've recently packaged SDL2 for Windows as a wheel, without any Python code. It is a conditional dependency "if Windows" for a SDL wrapper. Very convenient. It uses a little WAF script instead of bdist_wheel to make the package. https://bitbucket.org/dholth/sdl2_lib/src/tip
We were talking on this list about adding more categories to wheel, to make it easier to install in abstract locations "confdir", "libdir" etc. probably per GNU convention which would map to /etc, /usr/share, and so forth based on the platform. Someone needs to write that specification. Propose we forget about Windows for the first revision, so that it is possible to get it done. The real trick is when you have to depend on something that lives outside of your packaging system, for example, it's probably easier to ship qt as a wheel than to ship libc as a wheel. Asking for specific SHA-256 hashes of all the 'ldd' shared library dependencies would be limiting. Specifying the full library names of the same a-la RPM somewhere? And as always many Linux users will find precompiled code to be a nuisance even if it does run and even if the dependency in question is difficult to compile. On Fri, Jul 17, 2015 at 2:34 PM Olivier Grisel <olivier.gri...@ensta.org> wrote: > 2015-07-17 18:50 GMT+02:00 Marcus Smith <qwc...@gmail.com>: > > > > > >> I think Linux wheel support is almost useless unless the pypa stack > >> provides _something_ to handle non-python dependencies. > > > > > > I wouldn't say useless, but I tend to agree with this sentiment. > > > > I'm thinking the only way to really "compete" with the ease of Conda (for > > non-python dependencies) is to shift away from wheels, and instead focus > on > > making it easier to create native distro packages (i.e. rpm, deb > etc...that > > can easily depend on non-python dependencies) for python applications, > and > > moreover that these packages should be "parallel installable" with the > > system packages, i.e. they should depend on virtual environments, not the > > system python. > > +1 for being able to work in isolation of the system packages (and > without admin rights). > > This is precisely the killer feature of conda (and virtualenv to some > extent): users do not need to rely on interaction with sys admins to > get up and running to setup a developer environment. Furthermore they > can get as many cheap environments in parallel to develop and > reproduce bugs with various versions of libraries or Python it-self. > > However I don't see why you would not be able to ship your non-Python > dependencies as wheels. Surely it should be possible to package > stateless libraries like OpenBLAS, libxml/libxsql, llvm runtimes, qt > and the like as wheels. > > Shipping wheels for services such as database servers like postgresql > is out of the scope in my opinion. For such admin sys tasks such as > managing running stateful services, system packages or docker > containers + orchestration are the way to go. > > Still wheels should be able to address the "setup parallel dev > environments" use case. When I say "developer environment" I also > include "datascientists environment" that rely on ipython notebook + > scipy stack libraries. > > Best, > > -- > Olivier > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
