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.grisel@ensta.org> wrote:
2015-07-17 18:50 GMT+02:00 Marcus Smith <qwcode@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