[SciPy-user] Re: [SciPy-dev] Future directions for SciPy in light
of meeting at Berkeley
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
> 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
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