> > >> ok, but could/would the pip/wheel toolchain ever expand itself to handle >> delivery of external dependencies (like qt, tk, and numpy's "fortran >> stuff"). >> > > "fortran stuff" is pretty poorly defined -- I'm not sure we'd ever want > pip to install a fortran compiler for you.... >
to be very literal, I'm talking about this anaconda "system" package http://repo.continuum.io/pkgs/free/linux-64/system-5.8-1.tar.bz2 e.g., numpy's full requirement list in anaconda is like so (specifically for numpy-1.7.1-py27_0) openssl-1.0.1c-0 python-2.7.4-0 // not re-installed when using "conda init" readline-6.2-0 sqlite-3.7.13-0 system-5.8-1 // fortran "stuff" tk-8.5.13-0 zlib-1.2.7-0 > but Anoconda does some a nifty thing: it make s conda package that holds > the shared lib, then other packages that depend on it depend on that > package, so it will both get auto--installed > But I don't see why you couldn't do that with wheels. > exactly, that's what I'm really proposing/asking, is that maybe wheels should formally go in that direction. i.e. not just packaging python projects, but packaging non-python dependencies that python projects need (but have those dependencies be optional, for those who want to fulfill those deps using the OS package mgr)
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
