Re: [Distutils] Working toward Linux wheel support

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 <oliv...@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  -  Dist...@python.org> https://mail.python.org/mailman/listinfo/distutils-sig>