[SciPy-user] Re: [SciPy-dev] Future directions for SciPy in light of meeting at Berkeley

Bob Ippolito bob at redivi.com
Wed Mar 9 18:38:10 CST 2005

On Mar 9, 2005, at 4:50 PM, Stephen Walton wrote:

> Colin J. Williams wrote:
>> Stephen Walton wrote:
>>> Perhaps I'm in the minority, but I find CPAN counter-intuitive, hard 
>>> to use, and hard to keep track of in an RPM-based environment.
>> Debian has a nice package management system with a GUI (aptitude) to 
>> go on top of the basic apt.  This keeps track of  and enforces pakage 
>> dependencies.
> So does yum, and CPAN itself for that matter, but that isn't really 
> what I was raising.  If I use cpan to install 
> Perl::MyPackage::MyModule it doesn't show up when I do 'rpm -qa'.  I 
> can almost always say 'yum install perl-MyPackage-MyModule' though 
> with my repository collection.  Perhaps my main complaint is that the 
> CPAN divisions are just too fine grained.  Disk space is way cheaper 
> than my time, and I'd rather get everything I need in one go.

I also find that disk space is way cheaper than my time, however, 
building source packages (CPAN, DarwinPorts, etc.) can take *WAY* too 
long.  Especially for CPAN, where it asks you questions all the goddamn 
time, so you have to babysit.  That annoys me to no end.

Personally, I think the focus should be on repositories for win32 and 
Mac OS X binary packages.  Linux/BSD/etc. don't need yet another 
repository for packages, because they have systems like yum, apt, 
pkgsrc, etc. with an inherent distribution model.  If any distribution 
effort is put into the *nix OS'es, it should probably be to develop 
bdist_* targets so that it can integrate with the OS, not to develop 
One Package Manager To Rule Them All.  Not yet, anyway.

The best policy I have found is to build everything statically, taking 
advantage of whatever is already on the OS (for example, the ATLAS 
capabilities in Apple's Accelerate framework), so you don't have to 
worry about non-Python dependencies.  There are a couple exceptions, 
like SDL and wxWidgets, where it is better to go with the dynamically 
linkable version because you're going to have a bunch of things 
touching it.

Python dependencies can be managed rather simply just by maintaining a 
list such as X *needs* Y, Z.. however, it becomes more complicated when 
you have X *wants* Y.  Normally I just punt on this problem, and say 
that all wants are needs, so if you install a package you'll have 
everything it can do at the expense of downloading more stuff.


More information about the SciPy-user mailing list