[Distutils] Binary dependency management, round 2 :)

Marcus Smith qwcode at gmail.com
Thu Dec 5 01:06:31 CET 2013


>
>
>> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131204/a5c0c316/attachment.html>


More information about the Distutils-SIG mailing list