[SciPy-dev] Restructuring of SciPy

[Charles R Harris]

On Wed, 2005-08-17 at 14:31 -0600, Travis Oliphant wrote:
> After the 0.3.2 release, scipy will be getting a face-lift.
> 
> As part of that, I'm wondering about the restructuring process.  For a 
> long time, we've been operating under the "big-scipy-package" with 
> capability for small packages to be released separately model.  It has 
> had limited success and I don't know of any small packages actually 
> being released like that.
> 
> With things like Enthon out there that act as the "batteries included 
> super distribution" anyway.  It makes me wonder if we shouldn't move 
> scipy to the "scipy-modules" perspective directly and develop and think 
> about scipy has a collection of modules that work together smoothly 
> (i.e. naming conventions, etc.)
> 
> scipy_core + available instructions could provide all the infrastructure 
> someone needs to contribute packages to scipy.  This would also allow 
> people to develop (and maintain) their own modules (which they seem to 
> like to do anyway).  If we could just get them to play nice with the 
> rest of scipy_core, it would all be for benefit.
> 
> We already have the infrastructure in place for modules to play nicely 
> with the overall package.  I'm just wondering if we shouldn't emphasize 
> more the modular approach by the way the svn tree is layed out (so 
> individual modules can be checked out independently, for example).
> 
> I've also spoken to people who find it hard to rely on their scipy in 
> their code they pass on because you have to get the whole package, even 
> if you only use a few parts.  
> 
> Matlab also uses modules effectively. 
> 
> I think we should take advantage of the restructuring process to think 
> about this.
> 
> Comments?
> 
> -Travis

I think it is a good idea if:

1) There is good documentation so folks know which modules to get. For
instance, as far as I know, the zero finders are still in Optimization
and that is not the obvious place to look. Perhaps a package approach
combined with modules would work better. Or at least some sort of index.

2) It is possible to deal with module dependences.

The increasing number of programs also makes this desirable, as we can
include more and worry less about suitability.

-Chuck