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