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.
Distutils-SIG maillist - Dist...@python.org